On Mon, Apr 29, 2019 at 01:22:18PM +0000, Holger Levsen wrote: > On Mon, Apr 29, 2019 at 01:10:39PM +0000, Holger Levsen wrote: > > On Mon, Apr 29, 2019 at 03:08:49PM +0200, Santiago Vila wrote: > > > We can tell people to upgrade to the latest point release before > > > upgrading. > > > Every software vendor, not just so-called linux distros, recommend > > > such kind of things. > > thats not how Debian works since 20 years... > > as in: we can fix this properly (=not requiring people to read release > notes or doing special steps), and we should do that (=make it just > work). > > how: thats the open question I had in my initial reply to this bug > report to Andreas.
So, what kind of package relationship will fix this, and in which package? (Depends/Conflicts/Breaks). > > > As I said in the other bug, the root problem for this is to make the > > > error to be fatal. So, the time-bomb in stable is exploding now. Let > > > deactivate the bomb once and forever before it explodes again when > > > upgrading from buster to bullseye. > > you are again mixing bugs. > > as in: once we fix #928172 for the buster upgrade, we can apply the same > fix for the bullseye update, so #927450 doesnt become an "exploding time > bomb". This is where we seem to disagree. If I add a Breaks or a Conflicts in base-files, I would do it only for this time and only because we can't fix the package debian-security-support retroactively in stable (well, we could, but as you say, and I agree, we can't be sure that the user will upgrade to the latest point release before upgrading). However, I consider adding a Breaks to be a hack (or slighly hackish if you prefer). As far as the error in debian-security-support is fatal (i.e. the other bug you would like to ignore), we will have to repeat this Conflicts/Breaks thing again. That's not very appealing. So the "we can apply the same fix for the bullseye update" is what I dislike, because the fix will surely be hacky. I would not have to track debian-security-support releases every time I make the final base-files upload for a stable release. > if we now could please focus on #928172 and ignore #927450 for now, > that would be great. (and "ignoring #927450" also means not mixing them > up.) Let's focus on #928172 if you like. I try not to mix them up, but I believe they are strongly related in the sense that the reason #928172 is serious now is that the package in stable still has #927450. Thanks.
