Re: prerm for disappearing packages?
Jonathan Nieder 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?
>
[ why the exception was added in dpkg ]
My point is: if this exception was not exist, the things would be much
simpler. No one would try to explain why it is not here.
> [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.
Eh, no. Failed maintainer script results or in upgrade stop (which is a fault
of the package maintainer, and dpkg and front-ends have nothing to do with it)
or dpkg managers to call other maintainer scripts as a fallback, they succeed
(if they not, upgrade stops too) and upgrade continues.
>
> Ideally (well, my ideal): dpkg should learn to talk to front-ends
> through a pipe to avoid having to repeatedly reininitialize its
> state.
Well, dpkg has something like this ability (--command-fd), but it's not very
convenient to use. I would like to have libdpkg shared library instead with a
clean API to do things.
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.
I don't think automatic actions are good in this case. When you, literally,
pless 'y' in the front-end overview what packages will be
upgrade/installed/etc., you grants the package manager the right to do
precisely this actions. If postinst fails, executing it again makes little
sense (what would change by the time of the second run?), and manual
intervention needed.
That's my view.
>> Eh? How a package can disappear without reverse Replaces or forced file
>> conflicts ignoring?
>
> Empty directories can be replaced without Replaces.
So dpkg considers the package with only empty directories as non-disappeared,
but accepts all other packages replace them simply? Ouch, another unintuitive
rule regarding disappeared packages.
>> 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.
Summarizing my view, there is many assumptions and exceptions to rules created
just for make packages disappear, without, IMO, much benefit. The only benefit
- autoremoval of transitional packages - can be implemented on the front-end
side after, for example, front-end will know that this package is
transitional, so it will plan it's removal after installing its dependencies.
The natural thing would to remove disappear thing from policy and dpkg. But
since it's hardly going to happen in the near future, yes, it's worth fixing
that error. So, as I already said, I'm in favor of your patch implementing
that command line switch.
> By the way, I think cupt uses "dpkg --install" where possible, which
> avoids the errors in at least usual cases already.
Well, yes, it tries to do it that way.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
Reply to: