| 1 |
On Thursday 07 June 2007 01:44:39 Enrico Weigelt wrote: |
| 2 |
> > Now... Why are there multiple versions of java-config, |
| 3 |
> > autoconf, and automake shown on my system? |
| 4 |
> |
| 5 |
> These are packages totally incompatible and so different |
| 6 |
> packages under the same name. They're sometimes necessary, |
| 7 |
> since certain projects still require very old version, |
| 8 |
> even if upgrade wouldn't be such a problem and has already |
| 9 |
> been done by contributors (ie. mozilla). |
| 10 |
|
| 11 |
Well, they still are different versions under the same packages from the same |
| 12 |
projects. |
| 13 |
|
| 14 |
> Gentoo has an strange magic for handling that, called "Slots". |
| 15 |
> They deeply break the linear version space. This makes handling |
| 16 |
> very tricky and requires much additional complexity. Some of |
| 17 |
> the other replies should make clear some prolems ... |
| 18 |
|
| 19 |
I have no idea what breaking 'the linear version space' means. And I don't see |
| 20 |
how having automake in 7 different packages instead of seven slots under the |
| 21 |
same package makes it any less complex. |
| 22 |
|
| 23 |
How is having a depend on =sys-devel/automake-1.4* or sys-devel/automake:1.4 |
| 24 |
any more complex than a depend on a separate packages named |
| 25 |
sys-devel/automake-1.4 ? There are actuallly packages in the tree that don't |
| 26 |
care which version of automake is in use (at least according to there |
| 27 |
ebuilds). Now they just depend on sys-devel/automake. With your brilliant |
| 28 |
solution they would have to depend on || ( sys-devel/automake-1.4 |
| 29 |
sys-devel/automake-1.5 ... ). |
| 30 |
|
| 31 |
> No idea, why the responsible Gentoo-devs didn't just give |
| 32 |
> those incompatible packages different names, especially on |
| 33 |
> their own packages. AFAIK, java-config is made by Gentoo. |
| 34 |
> It would be trivial, just to call the 2.x version something |
| 35 |
> like java-config-2 ... perhaps too simple for them ? |
| 36 |
|
| 37 |
It still doesn't change the problem that if they have different files with the |
| 38 |
same name they need to install it in different places. That problem is just |
| 39 |
the same whether in slots or separate packages. |
| 40 |
|
| 41 |
[SNIP] |
| 42 |
> As someone else already that: one of the problems with slots. |
| 43 |
> They don't work well on cleanup. I wonder if anybody ever thought |
| 44 |
> about that when slots were introduced. |
| 45 |
|
| 46 |
--depclean does actually remove unneeded slots now for packages not in system |
| 47 |
or world. |
| 48 |
|
| 49 |
By removing slotting you take away flexibility and make things in a source |
| 50 |
distribution harder. Not easier. Yes, it sucks that our current EAPI doesn't |
| 51 |
support that flexibility properly (by allowing slot deps) and that our |
| 52 |
current package manager doesn't support the flexibility that use deps would |
| 53 |
provide (hence dying in pkg_setup when a use flag was required). But the long |
| 54 |
term solution is not to remove the flexibility that these concepts provide |
| 55 |
but rather to support it properly in the package manager and EAPI. |
| 56 |
|
| 57 |
-- |
| 58 |
Bo Andresen |
Archives