4 ms·

> The reply to that by the Gentoo guy (who started the Github issue) was that package maintainers cannot follow every single mailing list of every dependency.

> The reply to that by the Gentoo guy (who started the Github issue) was that package maintainers cannot follow every single mailing list of every dependency. It seems reasonable that, if you are the packager for critical packages, that you follow critical dependencies? If the problem is that the distro is supporting so many things that the folks working on it can't keep up - well, that's precisely the author's point: stop pretending that you can support HPPA and MIPS or whatever as well as you can support x86_64. But you don't get to tell a million people that they have to have a less secure Python because 3 people have a toy in a closet they want treated as a first class citizen.

FridgeSeal 6y ago
The number of people in the original thread who didn’t appear to be version pinning and then getting upset that a package that they directly relied upon automatically upgraded is eye-watering.
eyelidlessness 6y ago
> stop pretending that you can support HPPA and MIPS or whatever as well as you can support x86_64 And then the corresponding uptightness will be “FOO_PROJECT is aligned with the Intel monopoly”, and just as many people will be unhappy. You can see this in many recent threads about Apple not providing free access to M1 documentation for alternative OSes they’re under no obligation to support.
- rodgerd 6y ago
  That was, of course, a complaint about Linux back in the day. It turned out nobody cared enough to stop Linux development.
  - eyelidlessness 6y ago
    That’s pretty much verbatim the reply I had when people on here were prognosticating it for the M1, other than adding that they also promoted Linux virtualization in the announcement.
throwdbaaway 6y ago
Alright, let's do some digging... On 2013-03-21, urllib3 added an optional dependency to pyopenssl for SNI support on python2 - https://github.com/urllib3/urllib3/pull/156 https://github.com/urllib3/urllib3/pull/156 On 2013-12-29, pyopenssl switched from opentls to cryptography - https://github.com/pyca/pyopenssl/commit/6037d073 https://github.com/pyca/pyopenssl/commit/6037d073 On 2016-07-19, urllib3 started to depend on a new pyopenssl version that requires cryptography - https://github.com/urllib3/urllib3/commit/c5f393ae3 https://github.com/urllib3/urllib3/commit/c5f393ae3 On 2016-11-15, requests started to depend on a new urllib3 version that now indirectly requires cryptography - https://github.com/psf/requests/commit/99fa7bec https://github.com/psf/requests/commit/99fa7bec On 2018-01-30, portage started to enable the +rsync-verify USE flag by default, which relies on the gemato python library maintained by mgorny himself, and gemato depended on requests. So 5-6 levels of indirection at this point? I lost count. On 2020-01-01, python2 was sunset. A painful year to remember, and a painful migration to forget. And just when the year was about to end... On 2020-12-22, cryptography started to integrate rust in the build process, and all hell broke loose - https://github.com/pyca/cryptography/commit/c84d6ee0 https://github.com/pyca/cryptography/commit/c84d6ee0 Ultimately, I think mgorny only has himself to blame here, by injecting his own library into the critical path of gentoo, without carefully taking care of its direct and indirect dependencies. (But of course it is also fair game to blame it on the 2to3 migration) In comparison, few months before this, the librsvg package went through a similar change where it started to depend on rust, and it was swift and painless without much drama - https://bugs.gentoo.org/739820 https://bugs.gentoo.org/739820 and https://wiki.gentoo.org/wiki/Project:GNOME/3.36-notes https://wiki.gentoo.org/wiki/Project:GNOME/3.36-notes

FridgeSeal 6y ago

The number of people in the original thread who didn’t appear to be version pinning and then getting upset that a package that they directly relied upon automatically upgraded is eye-watering.

eyelidlessness 6y ago

> stop pretending that you can support HPPA and MIPS or whatever as well as you can support x86_64 And then the corresponding uptightness will be “FOO_PROJECT is aligned with the Intel monopoly”, and just as many people will be unhappy. You can see this in many recent threads about Apple not providing free access to M1 documentation for alternative OSes they’re under no obligation to support.

rodgerd 6y ago
That was, of course, a complaint about Linux back in the day. It turned out nobody cared enough to stop Linux development.
- eyelidlessness 6y ago
  That’s pretty much verbatim the reply I had when people on here were prognosticating it for the M1, other than adding that they also promoted Linux virtualization in the announcement.

throwdbaaway 6y ago

Alright, let's do some digging... On 2013-03-21, urllib3 added an optional dependency to pyopenssl for SNI support on python2 - https://github.com/urllib3/urllib3/pull/156 https://github.com/urllib3/urllib3/pull/156 On 2013-12-29, pyopenssl switched from opentls to cryptography - https://github.com/pyca/pyopenssl/commit/6037d073 https://github.com/pyca/pyopenssl/commit/6037d073 On 2016-07-19, urllib3 started to depend on a new pyopenssl version that requires cryptography - https://github.com/urllib3/urllib3/commit/c5f393ae3 https://github.com/urllib3/urllib3/commit/c5f393ae3 On 2016-11-15, requests started to depend on a new urllib3 version that now indirectly requires cryptography - https://github.com/psf/requests/commit/99fa7bec https://github.com/psf/requests/commit/99fa7bec On 2018-01-30, portage started to enable the +rsync-verify USE flag by default, which relies on the gemato python library maintained by mgorny himself, and gemato depended on requests. So 5-6 levels of indirection at this point? I lost count. On 2020-01-01, python2 was sunset. A painful year to remember, and a painful migration to forget. And just when the year was about to end... On 2020-12-22, cryptography started to integrate rust in the build process, and all hell broke loose - https://github.com/pyca/cryptography/commit/c84d6ee0 https://github.com/pyca/cryptography/commit/c84d6ee0 Ultimately, I think mgorny only has himself to blame here, by injecting his own library into the critical path of gentoo, without carefully taking care of its direct and indirect dependencies. (But of course it is also fair game to blame it on the 2to3 migration) In comparison, few months before this, the librsvg package went through a similar change where it started to depend on rust, and it was swift and painless without much drama - https://bugs.gentoo.org/739820 https://bugs.gentoo.org/739820 and https://wiki.gentoo.org/wiki/Project:GNOME/3.36-notes https://wiki.gentoo.org/wiki/Project:GNOME/3.36-notes