On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote: > On May 12, 2004, Axel Thimm <Axel.Thimm@xxxxxxxxxx> wrote: > > In general I don't see what purpose Alternatives would have. > > I can only speak for myself, but the reason I'd like to have separate > Alternatives would be to enable myself to keep a rawhide install plus > add-ons, such that, if some package from rawhide fails, I know the > problem is in rawhide, not in an external repository that accidentally > or intentionally brought in a different version of a library, program, > whatever. I realize kernel modules are a trickier issue, but on a > system meant to QA rawhide I wouldn't install them. For QAing rawhide (or any other release) I would really not install anything but the object to QA. A lot of "non-Alternatives" are plugins that alter the functionality of the system. So reporting back, that rawhide has great mp3 playback in xmms will not help QA ;) > Another reason is that most repos lag behind rawhide. Just to give an > example of one of my favorite pet peeves (without any offense to Dag > intended), Dag's FC1 has a mozilla 1.6 build with a higher epoch than > that of rawhide, even though his build is not actually more recent. > However, when I run up2date -u, it won't ugprade because of epiphany's > dependency on rawhide's mozilla, while dag's epiphany looks older than > that in rawhide so up2date won't use it. > > Sure enough, if the epoch wasn't higher than that of rawhide, I > wouldn't run into this problem. It would be lovely if this could be > fixed somehow, but there's no way for dag to downgrade the epoch > without breaking his <= FC1 repos, and blizzard didn't think this was > enough of a reason to bump up rawhide's mozilla epoch. That was a packaging buglet, of the kind that hurts whereever it happens: http://lists.atrpms.net/pipermail/repo-coord/2004-April/000240.html I think Christopher would bump up and fix the epoch, if the other repos would promise not to continue epoch-inflation. :) The problem there is less that of a missing Alternatives, but that of a lack of support of rawhide in most of the repos (until the last testing minutes ;). You will find yourself in the same unpleasant situation if you were using Dag's galeon or something else that relies on say FC1's mozilla and could block upgrading to rawhide mozilla. Same for any library upgrade that bumbs up the major version in rawhide, but has 3rd party packages relying on the old version. The way to attack these problems is to accept the fact that multiple incarnations of the same package should exist on a system (for packages that support this, like shared libraries). The current method of sometimes rebuilding compatibility packages is consuming too much time. Having packaging guidelines (like Mandrake/Debian for some areas) that allow concurrent use of different versions from the beginning will make mixing different ages of rawhide/FCN repos easier. The drawback is that old libraries not used by anthing else anymore will sit and occupy space. These need to be identified and removed. There are already tools for identifying these packages and defining a "Provides: allow-multiple-versions" or "Provides: remove-if-no-reverse-dependencies" guideline would make this model waterproof. While the first straightforward packages to dress that way would be shared libs, mozilla or gcc concurrent versions would also come to mind. At the very least this solves more than Alternatives and is useful even in fedora core/rhel by itself for deploying new libraries w/o repackaging compatibility libs and re-QAing the "new" compatibility packages. -- Axel.Thimm at ATrpms.net
Attachment:
pgpLQRibywcFA.pgp
Description: PGP signature
