Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi!
On Thu, 2010-04-08 at 15:08:56 +0300, Eugene V. Lyubimkin wrote:
> On Thursday 08 April 2010 14:32:20 Jonathan Nieder wrote:
> > I was reading some old material about trouble handling renaming binary
> > packages in a seemless manner [1] [2]. My main thought: this
> > shouldn’t be hard to fix.
> Secondly, AFAIK, Guillem Jover some time ago added a notice of
> disappeared packages to --status-fd dpkg output, so theoretically any
> high-level package manager can use it (practically, I don't know
> whether apt uses/will use it or not, but cupt does not, due to to
> 'Thirdly' below).
For reference, this was due to bug 537338. I've not checked but I'd
expect this would imply only few lines of code on the apt side, just
removing the just disappeared package from the to be configured queue.
> Thirdly, IMO this 'disappear' thing is a design flaw in dpkg/policy:
With this I disagree and I think it's a nice and useful feature to have.
> - Policy says that disappearted packages will not receive 'prerm'
> signal. Then, what's the point of having it when maintainer cannot
> guarantee it will be called?
Regardless of it being possible to call prerm by making the code in
dpkg more complex/intelligent, the thing is if it would be the correct
thing to do. Something to consider is that a disappearing package is
just one for which its files have been completely taken over by another
package, so arguably its contents do not get removed, they just change
ownership, and no maintainer scripts do get called either on
non-disappeared replaced files. So as I see it, the fact the the postrm
gets called is more to notify that the package state is changing and it's
going away (for which it might need to do additional cleanup) than that
the files got removed (which didn't).
The usual code run at prerm handles files getting removed which does not
apply here, as no files have possibly gotten removed. 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.
> - When you upgrades your system by some high-level package manager it
> usually says you that 'packages oldpkg and newpkg will be upgraded' (or
> 'newpkg will be installed and oldpkg is upgraded'). Once oldpkg gets
> suddenly dropped, it's inconvenient (at least) to high-level package
> managers, may confuse users, and, in case, just a lie. If the package
> manager says it will upgraded, it should be upgraded and not removed.
So even if it might be nice for the high-level front-ends to know before
hand what will happen during a dpkg run, the fact is, it cannot be known
and the front-end should be prepared to cope with unexpected state
changes. There's more to the installation/removal process than just
the metadata, there's the maintainer scripts which can fail at any
point, there's file conflicts, there's triggers, etc. And then there's
disappearing packages (even w/o an explicit Replaces).
The main reasons I chose to notify the front-ends via status-fd is so
that we don't need to add yet another force option which in this case
needs to be used always, and because it makes it explicit so that the
front-ends know exactly *why* the package is not there anymore, and they
can correct their view of the world accordingly.
> - The use-case for 'fast transition' doesn't look good to me, because
> when user will try to install the package he/she will see 'the package
> does not exist' instead of installing newpkg and transitional oldpkg.
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. I don't see the problem with the package not being installed any
longer, that's exactly what was intended to happen, in addition dpkg
should have notified via stdout and status-fd of what has happened,
and I'd assume the package description would state the package is
dummy/transitional/etc, so the situation should be pretty clear for
the user. Also dpkg will not disappear a package currently being
depended on.
regards,
guillem
Reply to: