| Summary: | [Future EAPI] Add support for multi slot dependencies | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Tiziano Müller (RETIRED) <dev-zero> |
| Component: | PMS/EAPI | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ciaran.mccreesh, ferdy, ferringb, hawking, wxwidgets |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=e383073de5bef8932f86d4f7d3dd09e7b5fd0c87 | ||
| Whiteboard: | in-eapi-5 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380 | ||
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. (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)? 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. |
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.