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
signature.asc
Description: This is a digitally signed message part.
