Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default
On Sun, 21 Mar 2010, Julian Andres Klode wrote:
> On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote:
> > > Otherwise, changing the essential package set would
> > > be a much more difficult thing.
> >
> > No, that's not true, and I wrote specifically about this case in the
> > initial message for this bug report.
> >
> > The truth is that it has never been a difficult thing:
> >
> > Whenever new essential packages have been added to the system, a
> > dependency on an already essential and required package has been
> > always added. Normally, the package which has a closer functionality
> > to that of the new essential and required package is chosen to carry
> > the dependency. If no package is particularly suitable for this,
> > base-files could be used as a last resort.
> AFAIK, something like this is not required.
Please elaborate. What is not required, exactly?
In the diff->diffutils rename, for example, yes, it was required that
diff becomes dummy and non-essential, otherwise there would not be a
way to remove it. A conflicts and replaces in diffutils would not work,
as that way there would be a time window in which the functionality is
not present at all (details for this in Bug#563895 at the very end).
So, I repeat: Please tell me a case where apt-get is required to act
as it currently does for which dependencies and dummy packages (that
we have always used otherwise) are not enough.
> > Conversely, when we want to drop (not add) an essential package, we
> > make it a dummy package first, for one release, like "mktemp" in squeeze.
> >
> > Ironically, what apt-get does in practice regarding the essential
> > package set is to make it really tricky to change it, i.e. the
> > opposite of what you said. See Bug #544481 for example, where the user
> > wants to get rid of diff, no longer essential in squeeze. He can't
> > because apt-get insist on considering diff as an essential package.
>
> Bug #544481 is a completely different bug; namely that packages are
> flagged essential instead of specific package versions. In my opinion,
> that one is a real bug; and apt should just allow to remove diff
> (although it would then reinstall it again; unless it is pinned to
> -1).
They are different, but not completely different, please see:
Bug #544481 says that apt-get considers a package essential if any of
their available versions is essential.
This is a bug because, for example, once you upgrade an essential
package like the real diff to a non-essential one like the dummy diff,
the old essential package should not be considered essential anymore,
even if it's available, i.e. it is the *currently* installed packages
the ones that decide which packages are essential, not the old available
ones, but for the same reason, not the *new* available ones either
(which is what I am complaining about).
So, no, these bugs are not so different IMHO.
This is the reason policy says that an essential package should not be
removed easily but it does not say that all essential packages should
be installed automatically.
Moreover, the algorithm of installing an essential package "just
because they are essential" is not consistent: In the e2fsprogs/e2fsprogs-foo
example, why would apt-get install one of them and not the other?
Just because one of them is required and the other is extra? Then apt-get
would be treating the essential status as a priority, which is not,
it's just a flag which means "do not let the user to remove me easily
if I'm installed". Nothing less, but nothing more.
> > > > Keeping the integrity of the system might be a desirable and nice
> > > > thing in some cases, but it's not something that should be done
> > > > *against* the will of the user!
> > >
> > > You can prevent the installation of new essential packages by
> > > pinning them to -1:
> > >
> > > Package: test-essential
> > > Pin: version 0.0-0
> > > Pin-Priority: -1
> >
> > That is better than nothing, but does not solve the problem. The user
> > who has already used dpkg --force-remove-essential should not have to
> > do that.
>
> Well, if you force dpkg to remove it, you can also just force APT
> to not re-install it again.
True, but in a well integrated system the user should not have to tell
things twice.
BTW: I have just made this experiment in a lenny system:
dpkg --force-remove-essential --purge mktemp
echo "mktemp hold" | dpkg --set-selections
apt-get dist-upgrade
and this time apt-get does not automatically install mktemp.
Is there a way to do the --purge and --set-selections at the same time?
This is better than I expected, but still I consider apt-get buggy
for installing a package "just because it's essential".
Reply to: