Re: fails to purge not RC

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Holger Levsen wrote:
> On Donnerstag, 16. Dezember 2010, Jonathan Nieder wrote:

>> Could you elaborate?  I would think that making "dpkg --purge" exit
>> with nonzero status would be serious, though perhaps of the can-defer
>> kind.
>
> It's annoying, it will probably leave cruft and it's a policy violation. But 
> that about it. The exit code is trivial to workaround (just expect that purge 
> will fail for some package, it's a safe bet) and there are basically no 
> consequences. (Except cruft on the system.) 

It means you cannot delete the old configuration and start over.
Sometimes packages include configuration that affects other packages
in the system (e.g., init scripts) and the ability to purge them
really is functionally important.

> At the end of this the dpkg database is in an ok state.
>
> So IMO nothing serious. Important, yes.

Ok.  I checked policy and all I can find on the subject is

	Each script must return a zero exit status for success, or a
	nonzero one for failure, since the package management system
	looks for the exit status of these scripts and determines what
	action to take next based on that datum

which leaves us with only common sense to decide the question "what
about maintainer scripts that never succeed?".  So policy agrees with
you.

(Breaking this feature of the packaging system is an important bug but
it seems it was never declared release-critical.  I am fine with that,
on reflection.)

>>> (Plus 27 packages, which even fail to install - but see #595652 for why I
>>> stopped filing those as serious atm and see
>>
>> Failure to install noninteractively sounds less severe[1] than failure
>> to purge.
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=595652
>
> You should have continued until msg=30 and 52 ;-) 

Of course I read the whole log.

> In short: failing to install non-interactivly is ie a problem for automated 
> installations and live-media builds. IOW: in getting the software deployed, 
> not getting rid off it. 
>
> At the end of this the dpkg database is _not_ in an ok state.
>
> That seems more severe to me.

I don't agree, especially because policy states the opposite directly
in §6.3.  In any event, it is hard to find an example of either of
these (broken noninteractive preinst or postinst, broken purge) that
is not a sign of major breakage.

Thanks for a useful clarification.
Jonathan