| Summary: | Clarify the difference between DEPEND and RDEPEND for strong blockers | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Davide Pesavento (RETIRED) <pesa> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | kingjon3377, kuraga333, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
The current wording is rather vague wrt strong (aka hard) blockers. Section 8.2.5.2 "Block Operator" of PMS just says: "If the specification is prefixed with one or two exclamation marks, the named dependency is a block rather than a requirement—that is to say, the specified package must not be installed [...] A weak block may be ignored by the package manager, so long as any blocked package will be uninstalled later on. A strong block must not be ignored." So, weak blockers are like PDEPENDs, it's not specified when they'll be uninstalled, but it's guaranteed they will be uninstalled eventually. For strong blockers, this could be interpreted as "invert the definition of {,R}DEPEND in section 8.1", i.e.: (a) !! in DEPEND -> the blocker must be uninstalled before any of the src_* phase functions is executed (but see [1]). (b) !! in RDEPEND -> the blocker must be uninstalled before the results of an ebuild merging are treated as usable. Point (a) makes sense, IOW it satisfies the use case of packages failing to build if an older version of themselves is already installed. As far as point (b) is concerned, well, I don't know what that really means. At any rate, I propose to positively define the semantics in both cases, instead of relying on a negation that is actually not a negation in the propositional logic sense. The "new" definition of (b) would be: the blocker must be uninstalled before the package replacing it is merged. This satisfies the use case of packages that have file collisions (e.g. a symlink installed on top of a directory) with earlier versions of themselves, while allowing the PM to automatically solve strong blockers and to minimize the period of time during which the package being upgraded is unavailable. All of the above might involve a semantic change which would require an EAPI bump, but otherwise the clarification seems a good thing to do. [1] What happens for binary packages that do not execute src_* phases? Can the blocker be ignored just like DEPENDs are ignored for binary packages?