On 2020-09-03 12:38, Alexis Ballier wrote:
>
> if some upgrade wants a package with unmatched deps (e.g. not installed
> at all or py38 usedep not satisfied), $PM will surely try to satisfy
> it by installing an ebuild. I don't think PMS specifies this, nor should
> it.
>
It's not an upgrade per se. The situation is roughly this:
1. User installs foo-1.2.3.ebuild, which supports python-3.7.
2. Developer ninja-edits the ebuild to support python-3.8.
3a. (crickets)
4a. Developer removes python-3.7 support from foo-1.2.3.ebuild.
5a. The next time something pulls foo-1.2.3 into the depgraph,
the PM will see that the installed version of foo-1.2.3 depends on
python-3.7, but that there is no python-3.7 in the tree or that
it's masked. Now emerge always fails.
or..
3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support.
4b. A user tries to install that revdep, but the PM sees that
the latest version of foo is already installed, and it (the
installed version) doesn't support python-3.8. Mysterious
error messages and manual intervention ensue.
What's happening is that the PM is using the metadata from the installed
version of the package, rather than the ninja-edited metadata in the
repo (how would it know which ebuilds were edited meaningfully?). That's
completely legal according to the PMS, and also the smart thing to do:
sourcing a few thousand lines of bash *just in case* there was an
important change in some ebuild is a huge waste of users' time.
Developers have an easy way to signal that there was an important
change: to bump the "r" number at the end of the ebuild. This forces any
upgrade involving e.g. foo-1.2.3 to pull in foo-1.2.3-r1, and the fact
that an upgrade is available is evident from `ls`, rather than from
sourcing a mountain of bash. One developer makes a change, and it saves
thousands of users each a lot of time. That's what we're all here for.
A package manager that uses the installed metadata is acting within its
rights (both pkgcore and portage without dynamic deps do it), so we
shouldn't be doing anything to break them in ::gentoo. Requiring
--changed-use is both insisting that users' waste time finding out
something that the developer could have told them, and also precluding
the use of a package manager that doesn't implement the (unspecified)
--changed-use flag in the same way portage does.
tl;dr the name of an ebuild is the only sensible (and PMS-compliant) way
to determine if something important changed inside it. The PMS says that
a new revision will be noticed by the PM, and it doesn't specify any
heuristics like --changed-use that ask the PM to (slowly) guess at it.
So, we should use revisions for these things.
