Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Philip Hands writes ("Bug#904302: Whether vendor-specific patch series should
be permitted in the archive"):
> Possibly also with something like this?:
>
> Post-Buster this should be implemented in Debian Policy by
> declaring that a package MUST NOT contain a non-default series
> file.
>
> The approach adopted to allow existing usage is left to the
> discretion of the Policy Maintainers.
Nit-picking, you might want to say
The approach adopted to tolerating existing usage before then
is left to the discretion of the Policy Maintainers.
Ian.
Bug#904558: What should happen when maintscripts fail to restart a service
Stuart Prescott writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson wrote:
> > When I wrote that, it didn't occur to me that anyone would think that
> > a failure by a postinst script to perform an intended operation should
> > be treated any other way than a failure of the postinst script.
>
> That was perhaps also written before we started to realise that maintainer
> scripts are actually best avoided
I don't think that makes any difference.
Whether things are implemented by handcoded code in postinst, or
dh-generated templatey postinst, or some kind of declarative system,
is important for manageability of our codebase etc. etc.
But it doesn't have any bearing on what the error handling should be
like. Any kind of declarative or automatic system or whatever ought
to have similar error handling: failure to perform an intended
function is an error and should not be ignored.
See for example the handling of errors which occur during trigger
processing.
One of the things that I am most proud of in dpkg is the comprehensive
and thoughtful error behaviours.
> > If the postinst fails, then the user has the opportunity to fix the
> > root cause and rerun dpkg-source --configure --pending. That will
> > then repair the system completely.
>
> \u2026 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.
This is a bug in apt, plain and simple.
Of course it is a design error, but that does not make it a bug.
There is nothing conceptually incoherent in installing strace while
cupsd and its dependencies are broken. dpkg will happily do it.
I agree that in the absence of a fix to this, some workarounds would
be good. Perhaps
dpkg --configure --force-postinst-fail broken-package
?
> 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.
dpkg is designed so that it is in general only the _configuration_ of
other packages which is blocked, not their actual upgrade. So
hopefully you should be in a reasonably coherent state.
> So while ignoring errors is wrong, so is making it harder to fix them. This
> isn't a question of absolutes.
As I say I think it is a bug in apt that when you have an error, apt
makes it hard to fix the error by insisting that you can't do anything
(even install diagnosis tools) until you have fixed the error (which
you can't do).
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#904558: What should happen when maintscripts fail to restart a service
Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts fail
to restart a service"):
> Ian Jackson:
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I think this is the core question. I largely agree with Ian here that
> having postinsts fail is not that big a deal if they can't make forward
> progress, but also we're being asked to advice on what happens when a
> maintainer script fails to restart a service. I disagree with him on
> whether failure to start/restart a service should be considered a
> configuration failure.
I think whether it is a configuration failure depends on ...
> I think the general rule should be that the success/failure of the
> postinst script should signal whether the package considers itself ready
> to provide whatever API it exists to provide (disregarding the case of
> Essential packages here, since those are special).
... that. I think I'm in agreement with you on that. But ...
> This means that failure to start a daemon should generally not cause the
> postinst to fail.
... I disagree with that. I think that in the usual case, if the
daemon is broken, and the package's purpose is to provide that daemon
service, then the package probably isn't providing its API.
Maybe part of the difficulty we are having with this conversation is
that we are lacking in examples. This bug and the "parents" #780403
and #802501 are all entirely abstract.
Would someone care to give some examples of packages which with both
behaviours ?
Also:
> The API provided by a package being in the configured state is not
> whether the relevant daemon is running or not; that is runtime and can
> and will change many times while the package is in the configured state,
> so dpkg dependencies are not useful for expressing "this service must be
> running".
I disagree with this.
dpkg dependencies are not just about what sets of packages can be
coinstalled. They also imply sequencing of package setup. And since
starting daemons is part of package setup, dpkg dependencies imply a
sequencing of daemon startup.
That is actually necessary in the case where the startup of daemon B
can only successfully completed if daemon A is up,
> (There's also the case where the service is running on a
> separate host, which is often the case for services such as databases
> and where the use of Depends is inappropriate.)
In that case, there would be a Recommends or Suggests instead, I would
have thought.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#904302: Whether vendor-specific patch series should be permitted in the archive
Tollef Fog Heen writes: > ]] Philip Hands > >> Tollef Fog Heen writes: >> >> >This should be implemented in Debian Policy by declaring that a a >>^^^ >> You've this doubled 'a' on two occasions in this text. > > I'll fix that, thanks for spotting it. > >> Presumaly we would not want to see new packages adopting the use of >> vendor-specific patch series prior to Buster. >> >> Do we need to make the "SHOULD NOT" conditional on the package already >> having a vendor-specific patch series at the time of this resolution? > > I think that just adds needless complexity and assumes that > maintainers will want to add bugs to their package. I really hope > that's not the case, so I don't think it's worthwhile to add extra > language for it. Well, I was thinking that we could simply state the MUST NOT as the general case straight away, but with a limited exception for packages that already contain the bug now, where that exception expires with the release of Buster. Your approach seems to require a timely update to policy post-buster, whereas if there's a conditional in policy there would be no urgency to removing it, so it can be done at the convenience of the policy maintainers. On reflection this seems like we're straying into micro-management. Should we really be determining the detail of how this is done in policy? How about this instead: The Committee therefore resolves that: 1. Any use of dpkg's vendor-specific patch series feature is a bug for packages in the Debian archive (including contrib and non-free), however existing use of this feature in packages should not be considered release critical until after the release of Buster. Possibly also with something like this?: Post-Buster this should be implemented in Debian Policy by declaring that a package MUST NOT contain a non-default series file. The approach adopted to allow existing usage is left to the discretion of the Policy Maintainers. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#904558: What should happen when maintscripts fail to restart a service
On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote: > ]] Ian Jackson > > Hi, > > > There may be good reasons not to treat daemon startup failure as a > > postinst failure, but the argument above is not one of them. > > I think this is the core question. I largely agree with Ian here that > having postinsts fail is not that big a deal if they can't make forward > progress, but also we're being asked to advice on what happens when a > maintainer script fails to restart a service. I disagree with him on > whether failure to start/restart a service should be considered a > configuration failure. I'm not sure why that position is even being considered valid. > The API provided by a package being in the configured state is not > whether the relevant daemon is running or not; that is runtime and can > and will change many times while the package is in the configured state, > so dpkg dependencies are not useful for expressing «this service must be > running». No. But it *is* a useful way to express "this service must be able to run". Additionally, if something fails to restart, then that is a serious problem that I, as a system administrator, would like to know about. Failure to configure a package signals that there is a serious problem that I need to fix, so that informs me. > (There's also the case where the service is running on a > separate host, which is often the case for services such as databases > and where the use of Depends is inappropriate.) > > I think the general rule should be that the success/failure of the > postinst script should signal whether the package considers itself ready > to provide whatever API it exists to provide (disregarding the case of > Essential packages here, since those are special). > > This means that failure to start a daemon should generally not cause the > postinst to fail. I think it should. If the daemon fails to restart, that means its configuration is incomplete or incorrect, which means the package failed to configure correctly. The failure to restart is just a symptom; the actual problem is the broken configuration, which may have further effects beyond just "the daemon won't restart". As such, in the general case, I think failure to restart is something that should cause failure to configure. There are really only two[1] reasons why a daemon could fail to restart: - The maintainer made a mistake in the default configuration, and the user didn't make any changes so the old conffiles are being replaced by the new ones, or the package is being newly installed; now the daemon encounters a syntax error. This is a bug, plain and simple, and catching bugs earlier rather than later is a good idea, which will happen if the daemon restart failure causes a postinst failure. - The maintainer made no mistake, but the upgrading user made some local changes, so the conffile system ensures that the syntactic differences in the configuration are not incorporated and the daemon fails to restart. As a system administrator, I would want to know when something like that happens sooner rather than later, so that I can fix it (also sooner rather than later). Failing to finish postinst correctly ensures that that does happen. This is now being countered by "but some people use tools that don't show failures to system administrators", from which the (wrong) conclusion is drawn "so we shouldn't fail anymore". It would be awesome if we lived in a world where we could avoid bugs in code and thus avoid all possible failures, but alas, we don't. So, given that failures *will* happen, even if we don't fail when daemons fail to restart, the correct conclusion would be "so those tools should be fixed to do their utter best to inform the system administrator when something failed". When those tools do that, failure to restart a service is no longer a problem for them, and we can continue to do the right thing. [1] There is also the possibility of "the package ships with incomplete configuration on purpose, because there are no sane defaults to use and installing the package requires manual steps from the maintainer before it can be made to work", but (a) our best practices recommend against doing that if at all possible, and (b) in that case starting the daemon shouldn't even be attempted from postinst, and so failure to start can't be a consideration in the exit state of postinst. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
