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
