Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi (again),
2010/4/9 Guillem Jover <guillem@debian.org>:
>> - 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).
I think what Eugene means is that the (front)frontends of dpkg will have no
way to display this action in the "what will change if you confirm this
action" view. Packages could disappear without that this package is
touched and even if it would be touched the displayed information is wrong,
as a package which will disappear isn't really upgraded.
Also, i think it feels a bit strange to "apt-get install git-core"
with the result that the package git-core is not installed as
it disappeared in the same call.
I am just thinking about a Joe Sixpack reading a tutorial about git which says
that he needs to install git-core which he does again after noticing that it
doesn't work at the first try and face a conflict resolution process now…
(or he had git already installed through some dependencies and is now
immediately confronted with this conflict.)
So maybe we should overload the Conflict+Replace+Provides triple for non
purely virtual packages like mail-transport-agent to define that the real
package with this name will disappear. (the "current" method for renaming
us it too - the difference between both is the versioned replace and both have
a versioned conflict, but pure virtual packages have no version, these three
groups are distinguishable from each other).
This isn't a complete solve - as far as i understand multiple packages could
replace different files in a package causing it to disappear - but it would
enhance the simple normal package rename case a bit.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
Reply to: