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 -- 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/20100409025754.ga28...@gaara.hadrons.org