| 1 |
On Fri, Dec 6, 2019 at 8:52 AM Rich Freeman <rich0@g.o> wrote: |
| 2 |
> |
| 3 |
> On Fri, Dec 6, 2019 at 8:06 AM Thomas Deutschmann <whissi@g.o> wrote: |
| 4 |
> > |
| 5 |
> > Sure, if packages don't work anymore or are blocking something, we will |
| 6 |
> > start last-rite process. But for the sabnzbd example (I haven't looked |
| 7 |
> > closely on any other package from that list) there isn't anything |
| 8 |
> > blocking and it's a working piece of software. The only thing which |
| 9 |
> > stands out is: It's a Py2-only package. |
| 10 |
> > |
| 11 |
> |
| 12 |
> Well, that's simple enough. If the python maintainers intend to |
| 13 |
> remove python2 then they need to remove anything that depends on it at |
| 14 |
> the same time. Otherwise all those packages are going to break anyway |
| 15 |
> and users just end up with a mess of error messages due to a broken |
| 16 |
> depgraph. |
| 17 |
> |
| 18 |
> That said, as I've already commented I think it makes more sense to |
| 19 |
> mask the reverse dependencies at the same time as masking python2 |
| 20 |
> itself. |
| 21 |
|
| 22 |
It's not quite so simple as you make it sound. There really isn't a |
| 23 |
viable way to defer removal of python2-only packages until we remove |
| 24 |
dev-lang/python:2.7. |
| 25 |
|
| 26 |
An increasing number of python packages are dropping support for |
| 27 |
python2 when upstream releases new versions. When this happens, we |
| 28 |
really need to drop python2 support from all reverse dependencies as |
| 29 |
well. Alternative strategies like slotting or compatibility packages |
| 30 |
are a stopgap at best, and become a problem as soon as bugs are |
| 31 |
reported or security issues pop up. |
| 32 |
|
| 33 |
Ripping out python2 support for all reverse dependencies of a core |
| 34 |
package is rather daunting, and is likely to cause much more of an |
| 35 |
uproar than the recent mask. Aaron is really tackling the low-hanging |
| 36 |
fruit at this point: leaves on the depgraph. |
Archives