Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi,
[ please CC cupt@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
Reply to: