Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hello (again),
2010/4/10 Jonathan Nieder <jrnieder@gmail.com>:
> David Kalnischkies wrote:
>> 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.)
>
> Why would he face a conflict resolution process?
What i thought was:
Hmm, the only content of oldPkg is a link from /usr/share/doc/oldPkg ->
/usr/share/doc/newPkg. newPkg includes also such a link.
Installing newPkg will cause the disappear of oldPkg.
If I try to install oldPkg again, what will happen?
(I thought it would be forbidden by the conflict - misread sorry)
After a quick test now with your testcase i noticed that oldPkg has
his link back(?) without further notice (or is at least marked as installed).
A follow up - maybe totally unrelated - dpkg call will cause the
disappearance of oldPkg. As it is not untypical for APT to call
dpkg multiple times in a row this will happen happen quite often in the
same APT call.
Assuming that someone will notice the one line disappearing in the dpkg
output is a bit to much - i am happy enough if a user notice the remove
section in the normal APT output before pressing 'y'.
Many libapt-frontends doesn't even show the dpkg text - only a progress
bar together maybe with the strings libapt emits on his status-fd.
I guess the frontends will loose a lot of trust if users start to notice that
they do something they haven't presented in advanced to the user:
They REMOVE packages - by far the evilest thing a package manager
can do… and additionally doesn't install a package they say they would
install (apt-get install git-core).
So in short: The frontends need to have a way to know in advanced that
a package will disappear in my eyes so the user can be informed.
I see a few options:
a) disappear + --ignore-not-installed
- yet another force flag -- and it will be passed to configure all
the time, so it is maybe even better to have a flag to force dpkg
to fail in this case than a flag to ignore this case.
- package managers can only present this to the user as a fait accompli
at the end of the run (if they parse --status-fd at all)
b) a) + overload Provides+Conflict+Replace
+ package managers can display it in advanced (renames)
+ package managers can prevent installation of oldPkg
if newPkg is already installed.
- doesn't handle more complex disappears in advanced
c) a new disappear status similar to removed-conffiles
-- a new status
- package managers will offer the remove in the next run,
not in the run it could disappear
- oldPkg can be reinstalled, will move to disappear and will
be suggested to be removed in the next run again
+ package managers can display it in advanced (all)
+ handles even the complexest disappears
d) drop of disappear completely, replace it with a transition
section and some autoremove magic
+ package managers can display it in advanced (renames)
+ package managers can prevent installation of oldPkg
if newPkg is already installed. (if it is not mixed with meta
packages - so maybe we should move to debtags?)
- no complex "disappears" allowed
I currently would favor b) -- at least the common simple rename
case can be presented easily in advanced.
The same could be accomplished by d) but i like the difference
between the rename which can really be done automatic and
the remove of some no longer needed dependencies which the
user need to check and approve.
Best regards / Mit freundlichen Grüßen,
David Kalnischkies
Reply to: