Hello, On Wed 29 Apr 2020 at 03:04PM +01, Rebecca N. Palmer wrote: > If a package has changed API since stable (in a non-backward-compatible > way and without changing binary package name), and/or is likely to do so > before next stable, is that a reason not to backport it? > > e.g. pandas has an open backport request [0], but broke 6 of 43 reverse > dependencies when tested before upload to unstable [1]. The ones I know > about can use Breaks:, but there may be more that I don't know about > because they don't have (enough) tests. > > Since backports are supposed to be kept up to date, a future release of > the package may add more Breaks. This could potentially be a security > risk if a user installs the backport, it stops updating when a later > version adds a Breaks: on something they have installed, and they hence > don't get a later security fix. However, the absence of a backport is > likely to cause users to obtain the package by non-Debian means (e.g. > pip or conda) that default to no automatic updates. I think that this is case-by-case. Everything you've written is relevant when deciding whether to upload something to backports and only someone with in depth knowledge of this particular package can trade them off. The only thing I'd like to add is that you should consider what other packages potential users of the backport are likely to have installed, or would be willing to upgrade to a version from backports. If you are breaking things they are not likely to have installed or would be fine to update from backports, then it's probably okay. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature