Re: prerm for disappearing packages?
Hi again,
Eugene V. Lyubimkin wrote:
> Guillem Jover wrote:
>> But if there was a
>> demonstrable need to run prerm script in this situation, I'd not see any
>> problem in an evaluation on adding such call.
>
> I wonder why that exception was added in policy then.
My impression is that policy was originally written as documentation
about dpkg’s design. Okay, that doesn’t answer anything. The
question is: why is that exception in dpkg?
Normally (i.e., for removal because of a conflict), if package A is
going to be removed and it’s package B’s fault, A.prerm is run
before any preinsts so it can complain and cancel the operation.
That’s wouldn’t be natural here, since dpkg only notices that A is
going to disappear after B has been unpacked.
Probably it never came up in practice, since tiny packages with preinst
are rare.
Now, given the explanation above, why do I think dpkg should run prerm
anyway?
Normally, if package A cannot be removed, that means trouble for
package B, and failure of its prerm has to wind the whole operation
back.
But that is not the case here. If A.prerm fails, there is still a
sane state we can resort to: cancel the disappearance of A and
leave a package with no files around.
The rationale is that that zombie package is still maintaining some
important information: for example, there may be old alternatives
maintained on its behalf, stale compiled bytecode, or lingering
daemons.
Unfortunately (for replaceable packages which preinst, which are rare)
this case requires some care on the part of the package maintainer.
Unlike in the "prerm upgrade" case, there is no guarantee that after
the prerm finally runs successfully, the replacing package’s preinst
and postinst are going to be called soon after.
[planning complex operations:]
> So, I would want to dpkg either implement this functionality itself or just do
> what front-end commands rather than notifying 'oh, I did something else, what
> next to do?'.
Well, how else can dpkg respect the maintainers’ wishes? A failed
maintainer script often has to result in a change of plan.
Ideally (well, my ideal): dpkg should learn to talk to front-ends
through a pipe to avoid having to repeatedly reininitialize its
state. When postinst fails, it would say so. Something to this
effect [1]:
pkgname postinst failed
pkgname is now in half-configured state
pkgname was being configured to respect an explicit "install" request
waiting for instructions
The front-end could say to continue with whatever remaining requests
are valid, or trying configuring pkgname again, or reinstall pkgname,
or whatever it wants to do.
This would be after the usual "error unwind". The idea is that dpkg
takes the status from one sane state to another, collaborating with
front-ends to decide what those states should be.
> Eh? How a package can disappear without reverse Replaces or forced file
> conflicts ignoring?
Empty directories can be replaced without Replaces.
>> I don't see the point of leaving cruft behind if the tools can
>> automatically take care of completely replacing a package with another
>> one. [...]
>
> This is a part I can agree with, though, stop. Hah. Correct me if I am wrong:
> new package got installed as a dependency of transitional package. So, it's
> automatically installed. Now, after upgrade the transitional package is
> removed, new package is alone and will be removed on next front-end run. Nice.
> Am I wrong?
I think you’re right about this. (Vincent Danjean also mentioned the
same thing in debian-devel@l.d.o.) So this trick is still not useful
for real packages, sigh.
I still think it is worth fixing the tools to support what policy
indicates. This means installing and disappearing a package in a
single run should not produce confusing “failed to configure” errors.
By the way, I think cupt uses "dpkg --install" where possible, which
avoids the errors in at least usual cases already.
Jonathan
[1] well, reusing the protocol from status-fd, not the ugly
pseudo-English of the example.
Reply to: