Hi Dirk, On 11-07-2023 02:43, Dirk Eddelbuettel wrote:
I still have hopes that we can let technical excellence rule and not require blunt instruments such as forced recompilation.
I'm totally on board for technical excellence, although I think we have different things in mind when we say that.
In Debian, with more QA than we ever had before, we're finding a class of issues that often went unnoticed years ago. One of these things is that partial upgrades can leave you in a bad state. So more and more we see that packages "have to" add Breaks to tell apt that when you want to upgrade package X, you also have to upgrade package Y if you happen to have that installed. As package Y can not tell that, package X has to add the Breaks on the broken version of Y. As an example, see the list of Breaks in libc6 [1]. While partial upgrades aren't officially supported, we rely on them nevertheless (even if only for QA (piuparts, autopkgtest)), and as a Release Team member I consider that class of fixes technical excellence: ensuring as best as we can that the user that upgrades a package keeps a working system.
While a rebuild of everything combined with bumping the "api" would achieve that, I'm much more in favor of targeted Breaks, like we have been discussing here. It's typically more work, but it's more correct.
For the future, with the recent change in dh-r, r-base will be much less impacted by this "problem" as the new uploads of reverse dependencies can migrate *before* r-base, and hence this class of issues will disappear once that happens (autopkgtest failures are retried after a day). So unless somebody investigates the issues in time, the retry will pass after the migration and the issue will no longer block r-base. I can live with that, but I find it a shame nevertheless.
So, what do you say: technical excellence and you add the Breaks? Or we let this slip in? I prefer the former, I can live with the latter.
Paul [1] https://tracker.debian.org/media/packages/g/glibc/control-2.37-5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature