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-de...@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. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409225417.ga23...@progeny.tock
