[Portland] Current plan summarized

[Ian Murdock]

On Thu, 2006-03-16 at 20:40 +0100, Kevin Krammer wrote:
> On Thursday 16 March 2006 11:12, nf2 wrote:
> > Kevin Krammer wrote:
> > > On Wednesday 15 March 2006 11:47, nf2 wrote:
> > >> I'm still not convinced regarding the static linking of the interface
> > >> library. We have not discussed this thoroughly and perhaps it's too
> > >> early to decide. I think there are two options here:
> > >
> > > Static linking has the advantage that starting an application on a system
> > > without "DAPI" support will not fail due to unresolved symbols.
> > >
> > > Of course there is always the possibility to have the API part of the
> > > library statically linked and the IPC part dlopen'ed.
> >
> > Perhaps a "strong" package dependency would be ok. Otherwise the
> > application developer has to deal with another fallback-case.
> 
> ISVs usually don't use package dependencies at all. They either link 
> statically or ship the shared library as well.
> Unless it is part of some kind of standard like LSB.

That's why the ultimate goal is to get Portland into the LSB, so ISVs
can know with certainty whether the runtime support is there without
the need for static linking or bundling the shared libraries or thinking
about fallback scenarios etc. If it's in the LSB, ISVs can use it
knowing it will work out of the box on LSB compliant systems,
which means every major distro they're likely to care about today.

I still have this nagging feeling we're making this more
complicated than it needs to be. What is being done in the DAPI
library that couldn't otherwise be done with a set of
scripts? With a script based approach, you don't have to worry
about ABIs at all, and trust me, if there's a way to do this
without having to worry about ABIS, you want to go that route.

-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige