Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?

["Bo Ørsted Andresen" <bo.andresen@zlin.dk>]

[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]

On Friday 08 June 2007 14:46:54 Enrico Weigelt wrote:
> > Well, they still are different versions under the same packages
> > from the same projects.
>
> Evolutionarily yes, technically no ;-P
> They're in fact very diffrent, but provide an very similar
> (almost the same) functionality.
>
> The problem is: upstream claims that newer evolutions steps
> were newer versions, Gentoo takes it as it is and runs into
> trouble, the attempt to fix this is slotting.

Wtf. Newer versions are newer versions. No matter if they are fully backwards 
compatible or not.

> If we simply would consider them as different packages,
> the whole story would be trivial. We just have to decide at
> which point a split has to be done. The whole complexity of
> slotting and the still unsolved problems (ie. cleaning up)
> could be dropped and dependency handling would be easy.

The point is from the package manager point of view it would be trivial 
*because* the developers would have to do more of the work manually. I.e. the 
work of creating new packages, removing old ones and creating/updating 
virtuals where they currently just do version bumps and remove old ebuilds.

I *really* don't see how adding seven versions of automake as seven packages 
in seven dirs plus adding a virtual that's provided by all seven of those 
versions is easier than just having seven versions in the same package with 
different slots. I also *really* don't see how adding a dep on =automake-1.4* 
or automake:1.4 is harder or more complex than automake1.4 (which currently 
would be an invalid package name anyway).

The reason why cleaning cannot be done properly for packages in system or 
world is that the packages files that define the system set in the profiles 
and the world file don't support specifying slots. At this point it would be 
pretty trivial to add both, however, the problem with that is backwards 
compatibility with older versions of portage itself. Profiles aren't 
versioned like ebuilds with an EAPI so there are no means to assure that 
people upgrade portage before getting profiles that are incompatible with 
older versions of portage.. Even today we still occasionally get bug reports 
from people who --sync with <portage-2.0.51 which aren't compatible with the 
current profiles (bug #114798)...

[SNIP]
> Same with autoconf. The numbering is not that easy here, since
> major breaks sometimes happen with minor version changes. So
> we just have to look a bit more cafully. But still much simpler
> as adjusting all these versioned dependencies which are necessary
> with slotting.
[SNIP]

Indeed the real problem is that the current EAPI supports neither slot deps 
nor ranged deps (with the exception of the not too powerful =foo* syntax).

> > > Gentoo has an strange magic for handling that, called "Slots".
> > > They deeply break the linear version space. This makes handling
> > > very tricky and requires much additional complexity. Some of
> > > the other replies should make clear some prolems ...
> >
> > I have no idea what breaking 'the linear version space' means.
[SNIP]
> The Idea of this "linear" version space is that we can compare each
> version with another one very easy. Additionally use the axiom that
> higher versions are always successors of lower ones and backwards
> compatible. In this situation the whole package management story
> is really easy. Things like slots are not necessary. If we also take
> in binary compatibility, revdev-rebuild is also not needed. Evrything
> is strictly defined in the dependency graph.

Wow. You're actually suggesting making a new package not only on API breakage 
but even on ABI breakage (otherwise revdep-rebuild would still be needed)? Do 
you *any* idea how many packages that would result in? It would be a 
maintenance nightmare. Keep in mind that CVS doesn't even support removing a 
package properly (with it's dirs).

[SNIP]
> > How is having a depend on =sys-devel/automake-1.4* or
> > sys-devel/automake:1.4 any more complex than a depend on a separate
> > packages named
> > sys-devel/automake-1.4 ?
>
> What if now comes an 1.4.99 which is totally incompatible with the
> other 1.4.* ? What do you do now ?

Add a 1.4.99 slot? Just like you'd create a new package for it and add that to 
the virtual?

> Drop that 1.4.99 ?
> Give it another version, ie. some 1.5.* ?
> Touch all depending patches to exclude 1.4.99 ?

Huh?

[SNIP]
> > > No idea, why the responsible Gentoo-devs didn't just give
> > > those incompatible packages different names, especially on
> > > their own packages. AFAIK, java-config is made by Gentoo.
> > > It would be trivial, just to call the 2.x version something
> > > like java-config-2 ... perhaps too simple for them ?
> >
> > It still doesn't change the problem that if they have different
> > files with the same name they need to install it in different
> > places. That problem is just the same whether in slots or separate
> > packages.
>
> Right. But that argument is neither for slots nor against.

So that still leaves me without a clue about what problem making 
java-config-{1,2} different packages rather than slots would solve.

[SNIP]
> > --depclean does actually remove unneeded slots now for packages
> > not in system or world.
>
> Well, I didn't prove it by myself - just took the input from this
> list, where people stated it would NOT do it cleanly.

The ability to do that has been added rather recently.

> > By removing slotting you take away flexibility and make things
> > in a source distribution harder.
>
> What flexibility do I take away exactly ?
> And what exactly gets harder ?

The ability to have more than one version of the same package installed at the 
same time. What is now a simple version bump (that happens to use a new slot) 
or cleaning of obsolete versions becomes packages additions and removals plus 
updates to virtuals.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]