Debian-python, Does anyone have thoughts on why some python packages use << versioning on build dependencies even when there are no such versions released? If this a python cultural upstream thing, is this something that should be mirrored in Debian's Depends: versioning? I'm guessing an upstream may want to protect against some potential future API break with a future version of some build dependency, to be certain to notice when upstream bumps versions and get a hard failure to be able to resolve things, but I'm guessing this probably does more damage than good if mirrored in the Debian versioning. Which happened now for yubikey-manager. I've not seen this used in other language ecosystems as much. But I may be missing something. Of course, if there is a KNOWN problem with a more recent version of some package, then a << dependency is fully appropriate. Btw, I just realized that maybe yubikey-manager could be team-maintained by the python team rather than the pkg-security team that I just nudged it into, I suppose people here will have more knowledge about python stuff than on pkg-security. /Simon Andrey Rakhmatullin <wrar@debian.org> writes: > On Fri, Sep 19, 2025 at 02:34:22PM +0200, Simon Josefsson wrote: >>> Note that the upstream pyproject.toml has "cryptography (>=3.0, <48)". >> >>I made a quick upload bumping <<44 to <<48. >> >>However why would one want to have these << dependencies? I guess they >>are mirroring upstream pyproject.toml, but I still don't understand the >>reason. > > It's an interesting question for which I don't have an answer, even > pyopenssl (notably maintained by the same PyCA as cryptography itself) > has a regularly bumped upper dep on cryptography. E.g. the recently > released 25.3.0 has the bump as the only change.
Attachment:
signature.asc
Description: PGP signature