On Tue, Feb 03, 2026 at 06:10:08PM +0300, Dmitry E. Oboukhov wrote:
How would this approach work for, say, Python packages listed in requirements.txt? Would we download them and package them as separate .orig archives?
In practice requirements.txt has a variety of meanings in Python-land due to the unfortunately-varied history of its packaging conventions. Sometimes it means "I have direct dependencies on these versions with these constraints". Sometimes it means something like "my CI processes will run tests in an environment using these particular versions, but the actual constraints are expressed somewhere else" (I think this is close to the preferred meaning). Sometimes it's kind of somewhere in the middle.
If you look at modern normative specifications, they generally say that direct dependencies are expressed using dependency specifiers in pyproject.toml or similar rather than by using exact pins in requirements.txt, but there are lots of old packages and considerable variety.
In any case, it's rare for such dependencies to actually translate into exact-upstream-version dependencies in Debian packaging terms, and the Debian Python team normally gets by well enough by using >= dependencies where needed, having as much autopkgtest coverage as we can, and dealing with actual breakage as it comes up due to build or autopkgtest failures.
-- Colin Watson (he/him) [[email protected]]
