Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 229521 - [Future EAPI] Add support for multi slot dependencies
Summary: [Future EAPI] Add support for multi slot dependencies
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: PMS/EAPI
URL: http://git.overlays.gentoo.org/gitweb...
Whiteboard: in-eapi-5
Keywords:
Depends on:
Blocks: future-eapi
  Show dependency tree
 
Reported: 2008-06-26 09:33 UTC by Tiziano Müller (RETIRED)
Modified: 2012-09-23 06:29 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tiziano Müller (RETIRED) gentoo-dev 2008-06-26 09:33:51 UTC
There are currently two issues with SLOT-based dependencies.
One which is a real problem and the other which would be nice syntactic sugar:
i) dependencies like DEPEND="cat/foo", DEPEND="|| ( cat/foo:1 cat/foo:2 )" are broken if cat/foo is slotted (example combination: sys-libs/db and net-nds/openldap)
ii) for packages with many slots (like sys-libs/db) it would be nice to be able to specify slot-ranges (something like DEPEND="cat/foo:{1-3}")

In this bug, we should only talk about part i), the second one should be done in a separate bug.

I'll explain the problem of the current (EAPI-1) SLOT-based dependencies with the example of sys-libs/db:

There are currently 7 slots for sys-libs/db: 1, 3, 4.2, 4.3, 4.4, 4.5, 4.6.

If a package works with exactly one specific slot, we have:
DEPEND="sys-libs/db:X.Y" and everything is fine.

If a package can work with more than one slot, there is no way to correctly specify this.
Example: OpenLDAP would work with sys-libs/db-4,{4,5,6}, but the following dependency-lines are broken:

DEPEND=">=sys-libs/db-4.4" .. includes the mentioned slots, latest one available will be picked. The package manager does not know which one and we therefore got two problems: i) the package manager can't warn or prevent the user from breaking his system by uninstalling one or more slots of sys-libs/db, ii) there is no easy (read: package-manager related way) to tell against which slot of sys-libs/db openldap has been linked against. This is cumbersome in the event of bugs which might be related to certain versions of sys-libs/db
iii) The package manager can't tell whether or not for which slots of sys-libs/db it should install updates but has to assume that it has to do it for all of them

DEPEND="|| ( sys-libs/db:4.5 sys-libs/db:4.6 )" .. has the same problem as above.

The only solution to this is to depend on exactly ONE slot: DEPEND="sys-libs/db:4.5"

So, what is needed:
* A way to tell the package manager from within an ebuild which slot of a dependency has actually been used if more than one got specified
* Therefore the package manager has to actually record the slot being used for building a package in the VDB
* A way to express in the depend whether the same slot being used to compile the package is also needed as a runtime dependency or whether a different slot may also satisfy the runtime dependency

Since this is a rather complex issue it would probably be a good idea to put together a separate document outlining the actual problem and the different cases to consider to solve this problem.
Comment 1 Tiziano Müller (RETIRED) gentoo-dev 2008-08-21 10:45:54 UTC
After discussing this on the gentoo-dev ml, it is enough to make the convention that a package depending on different slots of the same package must use the best match (maybe using best_version cat/foo ?).

A solution to the third problem is already given in the kdebuild EAPI.
Comment 2 Zac Medico gentoo-dev 2008-12-08 20:46:02 UTC
(In reply to comment #0)
> So, what is needed:
> * A way to tell the package manager from within an ebuild which slot of a
> dependency has actually been used if more than one got specified
> * Therefore the package manager has to actually record the slot being used for
> building a package in the VDB

These requirements seem somewhat backwards. Rather than the package deciding "automagically" which slot(s) will be used, shouldn't the user be able to control that (via USE flags or something similar)?
Comment 3 Ciaran McCreesh 2008-12-08 20:51:21 UTC
Doing it via use flags gets very silly for things with lots of slots, like db. If use flags were a decent solution people would be using them already.