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