On 30 August 2021 19:17:54 CEST, Christian Kastner <c...@debian.org> wrote: >On 30.08.21 15:49, Jelmer Vernooij wrote: >> I think one of the main challenges here is to make sure that the >> dependencies for packages in unstable/testing are correct. > >Why wouldn't they be correct, though? If it's less strict than it >should >be, then that is a bug. And if it's too strict, experimentation with >lowered requirements sounds somewhat dangerous. The approach I chose >was >to just backport any necessary dependencies as well. > >(...backport any necessary dependencies within reason, that is. For >example, some Python packages always have bleeding edge build >dependencies in setup.py thanks to dependabot, but a diligent >maintainer >will downgrade those to whatever the doc say is sufficient, I hope.)
There are two cases of insufficient version dependencies here - overzealous declaration of depending on the version in unstable and insufficient declaration of depending on the version in unstable. In my experience, a lot of packages don't declare the minimum version of a (build-)dependency that they need properly; upstream has started depending on a new version of a dependency and the package hasn't been updated. Instead, these packages fail to build or run when using the version of dependencies in stable rather than unstable. This is anecdotal though - I don't have any concrete data on how many packages would be affected. Maybe piuparts knows some of this? I agree it's a bug in those packages, but I think it would significantly affect backportability. This is somewhat orthogonal to the process of actually backporting, but it might impact the success chances or fitness of backported packages (if they end up pulling in a lot of unnecessary dependencies from backports). Perhaps the best path forward is to just attempt to backport every package in the archive and see how well that goes, and then iterate and fix issues that come up, such as incorrect versioned dependencies. Cheers, Jelmer
