On Sun, May 03, 2026 at 03:49:21PM -0000, Jeroen Ploemen wrote: > hi Pieter, > > my review for the beets package: > > * control: very specific version requirement for the dependency on > python3-acoustid (= 1.3.1), while the upstream pyproject.toml > specifies ^1.3.1 (note the caret) which if IIRC translates to > >=1.3.1,<2; > * control: the build-dep on sphinx <9 has been overtaken by reality, > with sphinx/9.1.0-1 already in unstable. Build seems to be fine > with 9.1.0 too though. > > For both of the above, it's often an open question whether version > restrictions declared by upstream are actually hard requirements or > just a matter of "we prefer to have everyone use the version we > tested with".
From my experience with various upstream projects, both individual authors with varying levels of experience and workflows, and more complex organizations (e.g. OpenStack), IMHO it is most useful to, at least initially, "assume good faith" and approach upstream requirements as follows: - lower bound (>= 6.0.2): treat it as a "should", but if the corresponding Debian package is still at a lower version and cannot be easily updated, attempt to build against it and see if the package still works (although some tests may need skipping, see below) - upper bound (< 8): again, treat it as a "should", but if the corresponding Debian package is already at a higher version, check whether this package will work with it; again, see below. For the lower bound, I personally believe that there are several most common reasons for the upstream author to set a specific version (but, of course, there may be a myriad of others): - the software uses a feature that was introduced in that version; in that case the Debian package will most likely require it, unless the functionality is sort of optional and can be disabled in some way that will not be very frightening to the users - some tests or static checker runs do not pass with lower versions; in that case it depends whether these tests will be executed at all during the Debian package build - there are various categories of tests that the upstream author runs, but it is not a really good idea for a Debian package to run as a blocking check, e.g. some static linters that change their behavior as their versions go up. Also, it is possible that these checks will not pass only under specific conditions, such as virtual environments created with "please use the lowest possible dependency version from any constraints, any level deep", so the problem may be in a second-, third-, etc. level dependency that actually is at a recent enough version in Debian. - the package dependencies are synced among several related packages, and only some of them are packaged in Debian at all; in this case it may be possible that the Debian version of the dependency is good enough for this particular package - the package dependencies are synced with some sort of packaging system (e.g. a suite in a Linux distribution, Nix, Guix, or something else); in that case it may very well be possible that the package will still work with the Debian version of the dependency - the package dependencies are generated automatically using some sort of toolset that makes decisions that do not really apply to Debian, such as "use the latest version" or "use a version that is no more than three months old" or "use a version with a non-zero minor version number" or "add up all the digits in the version number and only use it if the sum is even"; the last two are halfway ridiculous on purpose just to demonstrate that, yes, sometimes upstream's idea of dependency management deviates from ours :) In that case, again, it may very well be possible that the package will work with the Debian version of the dependency. For the upper bound, I believe that there are two most common reasons to set one at all: - there is an API break in the next major release of the dependency, and it affects this package's functionality; in this case, if we want to ship this specific version of the package, we most probably need to honor this dependency or, as in one of the cases above, check whether we can somehow disable the functionality that would break - the upstream authors are being conservative and careful and only want to make promises that they know will work, and at the time they released this specific version, they set an upper bound at "current major version + 1" so that if a new major version of the dependency is released on the very next day, this package will not break. In this case, we need to check whether the package will actually break with a newer version or whether any API breakages are in parts that this package does not use at all. If the package does work, we can relax upstream's upper bound. If the package does not work, we may need to backport a fix from a later upstream version or write one ourselves... or wait until the upstream authors release a version that will work. In any case, any time we decide to relax (including "drop") a version requirement, there are a couple of things that need to be done: - make sure any tests that the package runs during the Debian build will succeed; this may require either disabling some, or patching them to make them work with different versions of the libraries they use - try to run as many of the package's tests as possible, even those that are normally not run during the Debian build; if any of them fail, look at what failed and why and decide whether this may mean that a real-world use case of the package may actually fail, making users unhappy - make sure any Debian packages that depend on this one will still work; this is part of the "real-world use case" above :) - try to use the package "by hand" in various ways and see if they will work Thanks for reading this far :) And, of course, anyone may feel free to jump in with some reasons that I have missed or some factors that I have simply not come across yet in my personal experience :) G'luck, Peter -- Peter Pentchev [email protected] [email protected] [email protected] PGP key: https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
