Re: disappearing packages, seamless renames
Am 25. Mai 2010 23:18:50 UTC+2 schrieb Jonathan Nieder <jrnieder@gmail.com>:
> Nitpicks:
>
> The following packages have disappeared from your system
> because no other package depends on them and all files
> were overwritten by other packages:
> apt dpkg
>
> That dpkg is the program that does this should probably be mentioned
> in the manual.
(no counter arguments, just more details why i chose this text)
I don't include the depends thing as the root cause for dpkg
to even consider to disappear the package is that it has
no files left. That it has also no dependencies is "just" an
(important) safety-net.
A user seeing the list will ask itself why a package
disappeared - no files left is a good reason for it.
That it has no dependencies is the reason for an
autoremove package - this can't be done unattended
while the disappear happens auto-magic.
That is also the reason why the Note is displayed always
at the end to ensure that the user does not worry to much.
I should have added that the Note will disappear (haha)
if -q is given while the list is a bit more resistant
(as all other lists) and reacts only on -qq.
> 2010/4/10 David Kalnischkies <kalnischkies+debian@gmail.com>:
>
>> 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
>
> Unfortunately, Provides/Conflicts/Replaces is widely used as a synonym
> for Provides/Conflicts at the moment. But maybe in a couple of years
> this usage will be forgotten and we can revisit this.
>
> I have to admit I don’t like it at all. It is too easy to stumble
> on when you mean something else.
>
> I still prefer the idea of transitional packages having the "auto"
> bit passed on to dependencies[1]. When a package moves to the
> "transitional" section, package managers would know something
> interesting is happening, though it is true they cannot tell whether
> the package has been renamed, split up, or something else.
It can't be used for auto-bit passing as the section as requested
is for metapackages - if it gets implemented as in ubuntu currently
this will only mark the dependencies of a metapackage as manual
installed, so command series like
$ apt-get install gnome
$ apt-get remove epiphany-browser
$ apt-get autoremove
are no longer trashing the complete gnome stack as shown e.g.
in the blocked bug.
The rename case is different: If the oldPkg was manual installed
the newPkg should be marked as manual also - but if it was
auto-installed the newPkg should also be auto-installed.
I am currently thinking about transferring the auto-bit for disappeared
packages with the theory that a disappeared package only depends on
the package(s) replacing it - beside packages needed for the maintainer
scripts - but these should be eliminated with a check if the dependency
replaces the package…
Oh, and while i was able to add some logic to APT to eliminate the
need for an ignore flag for APT i think it should still be added for the
more simpler scripts and/or APT alternatives which don't want or can't
parse the status-fd - especially as dpkg doesn't really check
itself for disappearance if i understand the start of the thread correctly…
Best regards,
David Kalnischkies
Reply to: