1 |
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: |
2 |
> There are situations in which downstream overlays need to have versions |
3 |
> of python which Gentoo no longer supports in the tree. |
4 |
> |
5 |
> Currently, the only way to do this is for the overlay author to fork |
6 |
> python-utils-r1.eclass. This is highly undesirable since it creates a |
7 |
> very significant maintenance burden for the overlay author. |
8 |
|
9 |
Is it preferable to create the maintenance burden on Gentoo developers |
10 |
instead? Is it fair that paid company developers shift the burden |
11 |
on people who work on Gentoo in their free time, and already have their |
12 |
plate full? |
13 |
|
14 |
> The simplest way would be to apply the following patch. |
15 |
> In this situation, all the overlay author |
16 |
> would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. |
17 |
|
18 |
...which solves exactly zero problems because the eclass still doesn't |
19 |
support the implementation in question. The best it could do is sweep |
20 |
part of the problem under the carpet. |
21 |
|
22 |
Even if it miraculously works right now at all, it will probably fail or |
23 |
misbehave randomly. Any eclass change might break it. Then one cheap |
24 |
hack will serve as an excuse to add one more, and another. |
25 |
|
26 |
> The other option would be to move _PYTHON_ALL_IMPLS and the |
27 |
> implementation of _python_impl_supported to a separate eclass, e.g. |
28 |
> python-impls-r1.eclass. This eclass could be forked freely downstream |
29 |
> without worrying about the other python eclasses. |
30 |
|
31 |
Again, this doesn't solve the problem. It just moves the problem |
32 |
elsewhere. |
33 |
|
34 |
> Thoughts? |
35 |
|
36 |
I've already told you that if you want to fork, fork all eclasses. Then |
37 |
you wouldn't have to worry about internal API going out of sync. |
38 |
|
39 |
Or don't autoupdate ::gentoo when eclasses change. |
40 |
|
41 |
-- |
42 |
Best regards, |
43 |
Michał Górny |