On Thu, Jul 29, 2004 at 11:19:37AM -0400, Tim Daly wrote: > Lets suppose there are two incompatible libraries, like libc6 and glibc. > A maintainer will have to choose one for his taglist. He'll also have to > ensure that all of the packages he chooses work with his lib choice. A > similar problem occurs with the choice of desktop, KDE vs GNOME. You end up in a horrible mess very rapidly. I build ncurses with libc6 you build it with glibc, I want to install a package using each ncurses and now I'm already stuck > If we continue to use Core+Extras as concepts we'll have endless looping > discussions about why tuxracer must be in Core and even the kernel. It is You'll see those anyway, at least until there is a working Extras and there is a policy written. > converge to consensus. At least the maintainer concept allows fedora to > support diverse communities that don't agree on "fundamentals". In a sense you can already do this. Just put whatever you like in yum.conf and make subset repositories. Does mean duplicate disk usage so its not the final way to do it I grant. > >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. > > Repositories don't have to coordinate. Getting the distribution correct > and working is the maintainer's job. If the Computational Mathematics > taglist creates a bad build we know who to blame and who has to fix it. > If Core+Extras is broken there is nothing but finger pointing. Disagree. If computational mathematics clashes with childrens packages over a library both pulled from different 3rd party locations with differing configuration options where do you want to assign blame ? > Are you the Alan Cox of -ac fame? If so, surely you know about maintainers > in the kernel. The kernel is a bit different to a distribution - the model mostly works in kernel space due to a lot of communication and massive modularity. Plus its cheap to go "whoops, I'll fix that". A look at out of kernel device collections will also tell you we have most definitely *not* solved the problem space.
