FOSS and Interface Taxonomy levels

[Nicolas Williams]

On Wed, Mar 05, 2008 at 12:52:45PM -0800, John Plocher wrote:
> Nicolas Williams wrote:
> >> Volatile libraries that can be installed by the end user
> >> that have an architecture that allows the user to build
> >> self-contained silos of stuff?
> >> 	Probably extremely valuable
> > 
> > Examples?
> > 
> > Also, if such a library is "core" to more than one third-party app or
> > non-core FOSS, then how do we help prevent DLL hell?
> 
> 
> The key here is "self-contained silos of stuff".

OK.  Then why is the recent mail utilities case not instructive?  It
qualifies, IMO, as "self-contained," and it wasn't difficult (mostly
because the submitter, i-team, ARC and non-members participants
succeeded in finding a non-controversial mixture of Volatile and
Uncommitted).

Sure, finding a reasonable mixture of interface stability labels for
other cases may be difficult, but when the i-team understands the ARC
process, the interface taxonomy and its raison d'être, that should help
make things go smoothly.  When the i-team does not then this thread
invariably ensues.

> WSARC 2006/130 defined a mechanism to deal with
> "Multi-Installation and Management of Layered Products"
> where one could install multiple versions of components
> in different places so as to avoid the multi-DLL hell
> problem.
> 
> Think of
>      "/usr/local-apache1webstack/",
>      "/usr/local-apache22webstack" and
>      "/usr/local-appserverwebstack"...

Multiple versions.  The ARC has been averse to that.  Perhaps it should
be less so.  Either way, the same "find a suitable set of Uncommitted
and Volatile interfaces" advice applies, no?

> In effect, it says that, if you have multiple 3rd party apps
> that have non-resolvable conflicts with each other (or with
> stuff in the core), you install them into a silo of their own.
> 
> This trades "DLL-Hell because we need multiple versions
> co-installed" for "uses more disk space".

That works for some things.  OpenSSL and NSS challenge this world view.
But I think we're best off accepting some amount of DLL hell when it
comes to OpenSSL and NSS, and just ship multiple versions of them plus
warnings/guidance/whatever mitigations we can put together, + work with
the upstream communities to improve interface stability/documentation
and mitigate DLL hell.

Nico
--