| 1 |
On Thu, 2020-03-26 at 13:47 -0700, Patrick McLean wrote: |
| 2 |
> On Thu, 26 Mar 2020 21:11:11 +0100 |
| 3 |
> Michał Górny <mgorny@g.o> wrote: |
| 4 |
> |
| 5 |
> > On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: |
| 6 |
> > > There are situations in which downstream overlays need to have versions |
| 7 |
> > > of python which Gentoo no longer supports in the tree. |
| 8 |
> > > |
| 9 |
> > > Currently, the only way to do this is for the overlay author to fork |
| 10 |
> > > python-utils-r1.eclass. This is highly undesirable since it creates a |
| 11 |
> > > very significant maintenance burden for the overlay author. |
| 12 |
> > |
| 13 |
> > Is it preferable to create the maintenance burden on Gentoo developers |
| 14 |
> > instead? Is it fair that paid company developers shift the burden |
| 15 |
> > on people who work on Gentoo in their free time, and already have their |
| 16 |
> > plate full? |
| 17 |
> |
| 18 |
> We have no intention of shifting maintenance burdens anywhere, we want |
| 19 |
> to make minor changes to make it easier for us to keep up. It's the |
| 20 |
> same as a Gentoo developer asking an upstream project to make minor |
| 21 |
> changes to their build system to support DESTDIR or a sandbox fix. |
| 22 |
|
| 23 |
No, that's the exact opposite of it. Supporting DESTDIR is the correct |
| 24 |
course of action that benefits a lot of people. Adding hacks to make |
| 25 |
a broken thing to pretend to work is the exact opposite of that. |
| 26 |
|
| 27 |
> |
| 28 |
> > > The simplest way would be to apply the following patch. |
| 29 |
> > > In this situation, all the overlay author |
| 30 |
> > > would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. |
| 31 |
> > |
| 32 |
> > ...which solves exactly zero problems because the eclass still doesn't |
| 33 |
> > support the implementation in question. The best it could do is sweep |
| 34 |
> > part of the problem under the carpet. |
| 35 |
> |
| 36 |
> We don't care if it *actually* supports it, the ebuilds in question |
| 37 |
> aren't going to be installed on modern machines. We just want it to not |
| 38 |
> blow up in the global scope. |
| 39 |
|
| 40 |
Which makes literally zero sense. If you don't want them to work, |
| 41 |
remove them. Don't ask ::gentoo to provide special support to keep |
| 42 |
ebuilds that are 100% broken. |
| 43 |
|
| 44 |
|
| 45 |
-- |
| 46 |
Best regards, |
| 47 |
Michał Górny |
Archives