On Mon, 8 May 2023 at 21:09, Russ Allbery <r...@debian.org> wrote: > > Sam Hartman <hartm...@debian.org> writes: > > > As someone who has been following this, I support the work Helmut and > > Simon Richter have been doing. > > > I have more confidence in that view than the one Luca is proposing. > > I also support Shawn's interpretation that being conservative here is > > good. > > > I think even with my support we have no consensus. However hopefully we > > can get a few more people who have been reading the whole thread to > > chime in and a consensus will appear. > > I've also been following this. > > I appreciate Luca's questioning of the necessity of parts of the approach > and looking for simpler solutions; I think that's valuable feedback, and > we should avoid assuming that every conceivable edge case is supported in > Debian. There are unsupported edge cases in Debian already and likely > always will be because distributions are complex. > > That said, I find Helmut and Simon's analysis to be more persuasive so > far. I do think we should try to find a fairly robust solution, because > the feature we're trying to support here (smooth upgrades) is a core and > defining feature of what makes Debian Debian. That doesn't mean we need > to support literally anything someone might have done; that won't be > possible. But I think there are going to be enough unanticipated problems > that we should try to cover the anticipated problems, and that includes at > least the relatively obvious or known outside-of-Debian uses of things > like diversions. > > I would like to stay open to addressing some of those problems via > documentation or explicit upgrade instructions where that makes sense. If > we have places where there's a choice between writing extremely tricky and > complicated code versus providing people with simple instructions for how > to locate problematic diversions on their system, remove them before the > upgrade, and then put them back afterwards (or accomplish their goal in > some other way), we should consider taking the documentation approach > instead. But that still requires being able to enumerate at least the > most likely problems and understand them. > > For example, if local system administrators have been deactivating systemd > units by diverting them, at first glance I think it would be better to > clearly tell them that they should stop doing this and instead use > masking rather than writing code to try to ensure this continues working.
Obviously agree with your last point, I think documentation is fundamental for dealing with local changes. When I say that I don't think we should worry about strange local-only changes I mean exactly as you said, that I don't think we should start shipping complicated code that tries to deal with people diverting /sbin/init to /var/lolcat or whatever. Clear documentation that tells "if you did X look at Y and do Z" is the bare minimum I'd think. But again, I do think we need to try and define what it is that we want to support here. If we are serious about it, then we should codify it, and hold any future changes to the same standards, wherever they may come from. If we are not willing to do this, then I have to ask why. Kind regards, Luca Boccassi
