Stuart Prescott dijo [Wed, Sep 19, 2018 at 12:18:24PM +1000]: > (...) > That was perhaps also written before we started to realise that maintainer > scripts are actually best avoided as they tend to be complicated, fragile, > difficult to do right and make upgrades harder for the package manager. In > the intervening two decades, we've gone from "maintainer scripts are cool" > to "the best maintainer script is the one that doesn't exist". > > So yes, ignoring errors seems wrong but… > (...) > … causing a snowball of errors in an awkward half-upgraded environment is > nasty. > > The problem comes when you don't yet have the right tools installed to be > able to fix the problem. We see that scenario often enough in #debian where > someone has a failed upgrade and we try to collect more information via > pastebinit, strace, traceroute, netcat, gdb, etc; we frequently discover > that the relevant tool isn't installed and because apt is sufficiently > unhappy about broken packages and a half-completed upgrade, you can't ask it > to install the tool at that point in time. > > In the upgrade scenario, while you're trying to fix one particular problem, > you're also in a completely untested half-upgraded situation and so latent > bugs in any number of other tools may also be exposed. > > So while ignoring errors is wrong, so is making it harder to fix them. This > isn't a question of absolutes.
I completely agree with Stuart here. Yes, of course, there is a reason for maintainer scripts to exist, and if they fail to set up things around the package, of course, the user _needs_ to know something is off in their system. But that should happen _very_ seldom. As Stuart says, helping non-technical users out of this situation can be quite hard, and quite discouraging for the user. We have to make sure the scripts are as foolproof as possible — and failing to stop or restart a daemon it should _never_ cause the system to enter such a state.
signature.asc
Description: PGP signature
