Thomas Klausner <wiz%netbsd.org@localhost> writes: > In my eyes, there are two proper solutions here: > > * find and fix the issue in the old py-numpy package so it works for > python37 (and python27 if you're motivated) That's basically "remediating upstream", which is a game a lot of people would rather not play unless it is necessary. > * or mark the packages listed above, and the packages using them, as > not-for-python37. I think Dave's point is that if a package py-top depends on py-bottom and py-bottom is marked PYTHON_VERSIONS_INCOMPATIBLE=37, then py-top should simply inherit that without having to manually mark py-top as not for 37. I don't really understand the concern about people with 37 and updating pkgsrc. If someone wants to update pkgsrc on a machine to a newer branch (or current, but we're basically talking about people who are likely on branches), that means using provided binaries or building your own, but a consistent set. People using 37 and updating need to have all their modules working with 37 still, and that's increasingly non-viable. Really, the piont is that it's harder than moving whatever to 38 or 39, in almost all cases. If we are worried about people with custom code in 37 depending on python3.7 and not on any pkgsrc modules, we could drop 37 from the set of versions supported by packages, leading to python3.7 being in pkgsrc, but not building any py37-foo by default. I don't know if that's useful to people, but I think it would address Thomas's maintenance concerns. Alternatively, someone could adjust pbulk so that failing to find a py37-foo dependency would just be a warning in a separate section, and not show up as a broken package. I mean to just special-case py37, to basically say it's on thin ice and we as a group don't really care if python packages break on 37. People who care can of course still fix them.
Attachment:
signature.asc
Description: PGP signature