Bug 583544 – [Future EAPI] Add a dependency restriction operator that only applies to installed packages

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description Michał Górny 2016-05-20 06:42:20 UTC]

Not a final proposal but rather RFC for a problem that's troubling us already for some time.

Occasionally we need to require upgrades of some package due to API change but don't want to force it installed. For example, this was the case with late OpenRC API change.

The current solutions for that aren't good:

* regular dependency would cause OpenRC to be installed for everyone,

* USE dependency would introduce a lot of useless USE flags,

* blocker would cause confusing output to user, potentially even removing OpenRC instead of upgrading it.

I think Exherbo has some fancy magic resolution keywords to blockers for that [1,2].

My simplest idea would be to have a new pre-operator that would cause the dependency to apply only if the package of the same slot is installed (or if the blocker made of its negation would block?).

i.e.

  ?>=sys-apps/openrc-X.Y

would mean that if any version of sys-apps/openrc is installed, then >=X.Y is required.

  ?>=sys-apps/openrc-X.Y:S

would mean that if any version of sys-apps/openrc:S is installed, then >=X.Y is required.

Not that I like having extra magical characters but I think that's most in line with the parsing we have now, and should be relatively easy to implement using the current blocker resolution framework. It doesn't cover more complex cases like if package A forces deps on B -- but then, I don't think we really want to get into that.


[1]:https://exherbo.org/docs/eapi/exheres-for-smarties.html#package_dependencies
[2]:https://exherbo.org/docs/eapi/exheres-for-smarties.html#annotations

[Comment 1 Ulrich Müller 2016-05-20 09:13:17 UTC]

(In reply to Michał Górny from comment #0)
> My simplest idea would be to have a new pre-operator that would cause the
> dependency to apply only if the package of the same slot is installed (or if
> the blocker made of its negation would block?).
> 
> i.e.
> 
>   ?>=sys-apps/openrc-X.Y
> 
> would mean that if any version of sys-apps/openrc is installed, then >=X.Y
> is required.

So, for example, if a package depends on ?>=sys-apps/openrc-0.13 then openrc-0.12 would not satisfy the dependency, but no openrc at all would satisfy it? Is this only a different syntax for the blocker !<sys-apps/openrc-0.13 then, or what am I missing here?

[Comment 2 Michał Górny 2016-05-20 10:14:09 UTC]

Yes and no.

The major difference is that with blocker, Portage will often tell you to unmerge openrc (unless openrc upgrade is independently pulled into dependency graph). The main point in this is to avoid this confusion.

Additionally, the negative logic of blockers is often found confusing. Developers are more likely to do the right thing provided an explicit tool for it, than expected to use blockers which were designed to force uninstalls.

I think there's still debate if weak blockers are appropriate there since they are meant to handle file collisions.