Re: [gentoo-dev] RFC: ${PYTHON_COMPAT_ADD} in addition to ${PYTHON_COMPAT_OVERRIDE}

["Michał Górny" <mgorny@gentoo.org>]

W dniu wto, 16.01.2018 o godzinie 14∶09 +0100, użytkownik Francesco
Riosa napisał:
> 
> On 16/01/2018 08:57, Michał Górny wrote:
> > W dniu pon, 15.01.2018 o godzinie 16∶27 +0100, użytkownik Francesco
> > Riosa napisał:
> > > In late 2015 ${PYTHON_COMPAT_OVERRIDE} has been standardized and added
> > > to all python eclasses, it's useful for developers that want test and
> > > mark the package for newer versions of python.
> > > 
> > > However (unless I'm missing something) PYTHON_COMPAT_OVERRIDE is not
> > > usable if:
> > > - the user want only python 2.7 and 3.6 (latest) installed
> > >   no python 3.5
> > > - don't want to mess dependencies (the warnings in the eclass are scary)
> > 
> > Because it is not meant to be used for that purpose, and it is not meant
> > to be used by users at all! It's just a quick hack for developer who
> > wants to UNLIKELY(check if package works with implementation X) before
> > he starts the effort on modifying PYTHON_COMPAT in ebuilds.
> 
> supposed that, but at this point I fail to see the benefit versus the
> added complexity in the eclasses, however that's not my business.
> > 
> > > So, what can be done to let the user choose it's preferred python
> > > version(s) without having to build it's own overlay?
> > > 
> > > One solution is to change ebuilds in tree to include a user variable in
> > > the PYTHON* arrays, example:
> > > 
> > > -PYTHON_COMPAT=( python3_{4,5} )
> > > +PYTHON_COMPAT=( python3_{4,5} ${PYTHON_COMPAT_ADD} )
> > > 
> > > if someone want to bet that packages are ok with 3.6/latest (even before
> > > a developer tested it) then add PYTHON_COMPAT_ADD=python3_6 to
> > > /etc/portage/make.conf and run egencache.
> > > 
> > > Indeed biggest problem in changing $PYTHON* variables is that metadata
> > > also change and cache is invalidated.
> > > 
> > > However if the problem is known (*), and if the change to metadata is
> > > stable per "system"/"gentoo repo clone", then the solution to the
> > > problem is easy; just run $(egencache --update -j$(nproc) --repo gentoo)
> > > after each sync.
> > 
> > This won't work. You are wrongly presuming that egencache regenerates
> > cache unconditionally. It does so only if either ebuild or eclass
> > content changed. So it worked for you once because you modified ebuilds
> > and/or eclasses. It won't work when you change PYTHON_COMPAT_ADD.
> > 
> > I haven't checked the Portage details but it may see the metadata change
> > when installing the package. Which means it would install package with
> > unsatisfied dependencies (because it satisfied dependencies from cache),
> > then store the final dependencies and TADAAM, you've got broken
> > depgraph.
> 
> ouch, that basically kill the proposal, unless portage is modified to
> check known cache modifying variables, which isn't something I'd like to
> create.
> > 
> > > The most important thing is that this solution is scriptable and need no
> > > human intervention.
> > 
> > So is gpy-upgrade-impl.
> 
> It seem to do the job, one piece missing is something that monitor
> gentoo repository to see if it has better version (still w/o wanted
> python), an inotify for ebuilds. Suggestions?

None. I think Alec's idea would work better for you.

-- 
Best regards,
Michał Górny