Re: [gentoo-dev] Please port your packages to Python 3.8

[Alexis Ballier]

On Thu, 3 Sep 2020 14:17:06 -0400
Michael Orlitzky <mjo@g.o> wrote:

> 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.


py37 will (*) still be installed as it cannot be depcleaned because of
1. emerge won't fail since deps are satisfied.


(*) or rather should, but I think the only case that matters is a valid
system state where noone forced uninstall of a needed package or
manually rm'ed some random files

>
> 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.


precisely the case I wrote above: unsatisfied dep -> pull ebuild.
non-issue too.


> 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.

you seem to be confusing dynamic deps and unsatisfied deps here. A
package installed with py38 disabled (e.g. after a revbump) or no py38
support at all (e.g. without revbump) will not satisfy a [py38] usedep
in any case so will work just the same


> 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.

fixing non-issues does not seem so important to me :/

[...]