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: 2823 bytes --]

On Thursday 07 June 2007 01:44:39 Enrico Weigelt wrote:
> > Now...  Why are there multiple versions of java-config,
> > autoconf, and automake shown on my system?
>
> 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.

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

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

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

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

By removing slotting you take away flexibility and make things in a source 
distribution harder. Not easier. Yes, it sucks that our current EAPI doesn't 
support that flexibility properly (by allowing slot deps) and that our 
current package manager doesn't support the flexibility that use deps would 
provide (hence dying in pkg_setup when a use flag was required). But the long 
term solution is not to remove the flexibility that these concepts provide 
but rather to support it properly in the package manager and EAPI.

-- 
Bo Andresen

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