[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#574729: apt: essential is not a priority. apt-get should not install essential packages by default



On Sun, 21 Mar 2010, David Kalnischkies wrote:

> 2010/3/21 Santiago Vila <sanvila@unex.es>:
> > 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).
>
> And in which way apt should know that you no longer have a package from
> e.g. stable which requires the functionality of package X which is in testing
> no longer essential? The closest match is that if you removed the sources
> for stable you have fully upgraded to testing.

apt does not know such thing, and I don't think it is supposed to know.
IMHO, it should only care that currently installed essential packages
are not removed without a strong force option (like the one that asks
the user to write "yes i know this is bad" or something alike).
Upgrading them is always ok.

As we (claim to) support partial upgrades, if the user upgrades
essential package X in stable to non-essential package X in testing,
dependencies in stable and testing should already be ready for that,
regardless of the user using apt or not, as apt is not the only
installation method. We will surely need two releases to do it right,
for example: In oldstable, it's decided that package X will become
non-essential. In stable all packages that need it are required to have a
dependency on it. In testing, package X may drop its essential status
and everything would work, unless the user mixes packages from
oldstable with packages with testing, which I don't think it would be
officially supported.

This is for the case in which some essential functionality is dropped.
When such functionality is simply moved from one package to another
one, dependencies and dummy packages allow it to be done in a single
release.

> [...]
> > 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.
> I would be really interested in the difference. If you haven't removed it,
> why apt wants to reinstall it then?

I discovered about this apt-get "feature" by installing The Hurd on kvm
recently, since you ask. The default system did not include a package which has
the essential flag, and to my surprise it was installed automatically, without
asking, and without having the chance to say "no". I felt dissapointed.

> dpkg also allows you to install a package and ignore its dependencies,
> so apt shouldn't try to fix this? The job of APT is to prevent the user from
> dependency hell, essentials are here to prevent the archive from too many
> dependencies. If APT would stop taking care of dependencies - and
> essentials are the hardest form of dependencies (They are always installed,
> will never be removed and work even in unpack state.) - the sole idea
> behind APT is destroyed?

I never said that installing essential packages is always bad. My point
is that it should not be done automatically, as the letter of policy
does not dictate such thing.

Either the user is asked about it or maybe a short message is
displayed explaining why additional packages are installed.

> What you could try with your package is Provide+Conflict+Replaces the
> essential package - apt will not come up with a solution to this "problem"
> itself as we will have a (short) time frame in the transition in which no
> package is installed providing the functionality so you still have to go over
> dpkg force flags, but at least in theory apt should notice with the provides
> that a package with this functionality is installed after that.
> Another thing you can try is installing a dummy package with this name
> and an exorbitant high version number?

Sorry, I am a little bit lost here. To which problem the last
paragraph is a suggested solution?



Reply to: