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

[Enrico Weigelt]

* Bo Ørsted Andresen <bo.andresen@××××.dk> wrote:

Hi,

> > These are packages totally incompatible and so different
> > packages under the same name. They're sometimes necessary,
> > since certain projects still require very old version,
> > even if upgrade wouldn't be such a problem and has already
> > been done by contributors (ie. mozilla).
>
> 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. 

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.

For example gtk:

First there was gtk-1.x. Later came gtk-2.x. They never were
compatible (except maybe early alpha state ;-)). They always
have been different packages, very similar, but different.

So if gtk-2.x would simply be called gtk2, the whole idea of
slotting wouldn't be necessary here. There are packages depending
on gtk and others depending on gtk2. Trivial.

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.

Maybe it would be different if the slot number would be essential
part of the package atom. But I'm not sure if it's really necessary
to have such an additional complexity if there is an clear scheme
for putting those "evolution levels" into the package name.

Gentoo always tries to stay as near as possible to the upstream.
Thats okay, if we're talking about patches. But taking those crappy
versionings from the upstream IMHO produces unnecessary trouble

> > 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.

Let's try some little (some bit mathematic) definition:
 
Version numbers are living within an scalar 1-dimensional space, 
ie. like rational numbers, but with holes. (ups, it's not really 
linear if we have holes ;-o). But all numbers are comparable with 
<,>,= operations. We normally represent them as n-vectors, ie. in 
form of 1.2.3.4 but in fact the right side dimensions are intervals
in the left side ones. Assuming the digits may take 0..9, we could 
define the scalar value of A.B.C.D as A*1000+B*100+C*10+D ...

(My Briegel buildsystem, which is a little bit like portage, but for 
embedded/crosscompiling, uses this model as well as the Comprehensive
Source Database ;P)

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.

> And I don't see how having automake in 7 different packages instead
> of seven slots under the same package makes it any less complex.

It WILL make it easier. The whole slot handling could be dropped off
(makes the code much easier) and the problems with slots simply 
would not exist. 
 
> 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 ? 

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

> There are actuallly packages in the tree that don't care which version
> of automake is in use (at least according to there ebuilds). Now they
> just depend on sys-devel/automake. With your brilliant solution they
> would have to depend on || ( sys-devel/automake-1.4
> sys-devel/automake-1.5 ... ).

Simply add an virtual for that ? 

BTW: (beside rare cases), ebuilds normally sould have no variants
in their dependencies - this should be left to the virtuals, IMHO.

> > 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. 

> [SNIP]
> > As someone else already that: one of the problems with slots.
> > They don't work well on cleanup. I wonder if anybody ever thought
> > about that when slots were introduced.
>
> --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.

> 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 ? 


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-user@g.o mailing list