Hi, [ please CC c...@p.d.o as well in all future front-end-related issues too ]
Guillem Jover wrote: >> 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. Features are always nice to have, unless they breaks the design, which is IMHO the case here. > >> - 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 Eh? The 'master' package can overwrite files with the same paths but different context, so I don't consider them "dpkgchown'ed". > and no maintainer scripts do get called either on > non-disappeared replaced files. Which is also bad IMO. > 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. That's non-technical. Or you guarantee, or you don't guarantee. Policy doesn't operate with 'more to notify' and 'usual code', fortunately. If the maintainer wrote that script prerm/postrm, it is important to do something in it. > 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. >> - 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. So that's probably the main point where we disagree. I consider this behavior as a severe design flaw, because dpkg play double standards here. It doesn't produce a sequence call for mass action by itself, passing that task to front-ends, but considering normal to modify it. FTR, in Cupt the code for generating such a sequence is a most complex thing, algorythmically, over the whole code base, beating such a monster as problem resolver. FTR2, the most popular implementation, libapt-pkg one, still has bugs regarding doing it. 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?'. The fact it cannot be known is another side of such of this flaw. If we forget for a minute about disappearing packages, it should be known. > 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. It's not the problem of dpkg or front-ends. I think we are discussing a problem with good, polished packages, but failed upgrades. > And then there's > disappearing packages (even w/o an explicit Replaces). Eh? How a package can disappear without reverse Replaces or forced file conflicts ignoring? > 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. Well, you know, if I'm a driving a car on the road, I assume there are no walls on it. If you notify me "a wall next 10 meters", I will success to change my mind, but avoiding the wall will be very hard. In this case (disappearing packages) it may be possible. But in general I disagree. >> - 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. [...] 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? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- 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/4bbf4892.8090...@gmail.com
