The hard problems with Collections: (Was: tuxracer & chromium move to Extras_

[Bill Rugolsky Jr.]

On Thu, Jul 29, 2004 at 11:56:57AM -0400, Alan Cox wrote:
> Equally the original definition recognized people would want to do things
> that broke compatibility with core components and that users should be able
> to tell this would happen - Fedora Alternatives being the tag name we used
> for such packages. That might be as mundane as a gnome-libs variant with
> new features or as significant as using the FreeBSD kernel or Hurd as the
> core kernel.
> 
> There does seem to be an O(N^lots) co-ordination requirement between main
> repositories and we must be careful of that. Maybe Conary will, once half
> of it has stopped being armwaved, solve that.

I think Conary is a wonderful idea, but until dependency handling is factored
in, we have no way of knowing whether the model that is working for the
kernel will scale up to the level of a distribution.  I think much of
it will depend on the actual depth of the graph of real-world dependencies.

Currently, the interfaces of both kernel and libc are fairly static, and
care is taken to maintain compatibility, so things like Andrew Morton's
-mm tree, which now includes plenty of other changes by reference,
actually results in a working system.  But when we take that into the
realm of something like GNOME, it is quickly apparent that one may need
to have many versions of libraries, config files, etc.  Just moving from
the stable to the development branch of an application like Gnumeric is
a headache, involving numerous library upgrades.

(Efficient) virtual environments like Linux Vserver that provide isolation
are garnering attention not simply to run hosting services, but because
they offer interesting management possibilities, like the the ability
to install and test new versions of a complex cluster of applications
(say Apache Tomcat/Jakarta, bugzilla, gforge, etc.) on the same host
with the old versions.  Perhaps coupled with something like Conary, this
would provide an efficient mechanism for reducing risk while staying
close to current.

It would be nice to see vserver-like functionality accepted upstream, and
the completion of Al Viro's namespace work, including per-mountpoint
flags, partial namespace sharing, union mount, unionfs, etc.

Regards,

	Bill Rugolsky