Alternatives and packaging policies for multiple installs of different versions (was: On disttags)

[Axel Thimm]

On Thu, May 13, 2004 at 02:54:11AM -0300, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040513/dc5d0502/attachment-0002.bin