Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #17078

Re: Bug#1115706: Not installable with python3-cryptography >= 44

From Simon Josefsson <simon@josefsson.org>
Newsgroups linux.debian.maint.python, linux.debian.bugs.dist
Subject Re: Bug#1115706: Not installable with python3-cryptography >= 44
Date 2025-09-19 15:20 +0200
Message-ID <LwJbP-gy7c-3@gated-at.bofh.it> (permalink)
References <LwElQ-guYd-3@gated-at.bofh.it> <LwIz7-gxBR-11@gated-at.bofh.it> <LwElQ-guYd-3@gated-at.bofh.it> <LwIIN-gxFI-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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.

Back to linux.debian.maint.python | Previous | NextNext in thread | Find similar


Thread

Re: Bug#1115706: Not installable with python3-cryptography >= 44 Simon Josefsson <simon@josefsson.org> - 2025-09-19 15:20 +0200
  Re: Bug#1115706: Not installable with python3-cryptography >= 44 Stefano Rivera <stefanor@debian.org> - 2025-09-19 17:30 +0200
    Re: Bug#1115706: Not installable with python3-cryptography >= 44 Stefano Rivera <stefanor@debian.org> - 2025-09-19 18:00 +0200
      Re: Bug#1115706: Not installable with python3-cryptography >= 44 Simon Josefsson <simon@josefsson.org> - 2025-09-19 18:30 +0200

csiph-web