On Thu, Mar 26, 2020 at 08:37:17PM +0100, David Seifert wrote:

*snip*

> How do you prevent some extra clever Gentoo developer from doing the following
> in ::gentoo
> 
>   dev-python/foo/foo-1.ebuild:
> 
>   # don't have the time to port this right now, patches welcome
>   PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 )
>   PYTHON_COMPAT=( python3_4 )
>   inherit distutils-r1
 
 If there's a way inside an eclass to check that the ebuild inheriting
it is in ::gentoo, I will use it to die if the ebuild is in ::gentoo
and this variable is set.

> Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break 
> metadata
> invariance, causing tons of cache mis-hits. How do you prevent that?
> 
> In addition, this will very quickly cause whatever overlay this is being used 
> in
> to become invalid. Imagine I have dev-python/foo::gentoo that supports python
> 3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a
> hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove
> python 3.4 from ::gentoo in python-utils-r1, and one week later we remove
> python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev-
> python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an
> invalid depgraph. How do you wish to resolve this?

These are both overlay maintenance questions that wouldn't affect
::gentoo, but the answer to the first one is we regenerate the metadata
very often so it wouldn't be an issue, and the second one is  resolved
by grabbing packages and putting them in another overlay until we don't
need them.

> I feel like keeping up with ::gentoo is ultimately the better strategy than
> trying to add backdoors to eclasses because some overlays are somewhat behind.
 
I agree with you. However, sometimes in the real world it doesn't work
that way, or it can take longer to move than Gentoo.

If we can do something minimal to allow downstream overlays to do what
they need to do to catch up, I think we should, especially if someone
from downstream is offering to do the work.

William

Attachment: signature.asc
Description: Digital signature

Reply via email to