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

Re: FAQ: Essential vs. Required



Osamu Aoki wrote:

> Santiago Vila wrote:
>
> > Imagine an e2fsprogs-cvs package which conflicts and replaces the
> > normal e2fsprogs package. It should be extra, but if you install
> > e2fsprogs-cvs to replace e2fsprogs, you should still be unable to
> > remove e2fsprogs-cvs unless you use dpkg's --force-remove-essential
> > option. So, a package like e2fsprogs-cvs should still be essential: yes
> > to prevent its removal the same way e2fsprogs does.
>
> But we do not have e2fsprogs-cvs.

It does not matter. We are talking about what policy allows or forbids,
not about what we have or do not have currently.

> I was looking for actual examples of this type of case.  If we
> really have this kind of case, it is bast to make e2fsprogs not
> "essential" but let some essential package depends on it.

I don't think it would be better at all. e2fsprogs is essential.
You need dpkg --force-remove-essential to remove it. If you installed
a hypothetical e2fsprogs-cvs package, you would still need
dpkg --force-remove-essential to remove it.

However, a dpkg --force-depends would be enough to remove a package on
which an essential package depends.

Since I believe --force-remove-essential is generally considered
as a stronger thing than --force-depends, it would be "easier"
to remove e2fsprogs if it wasn't not essential by itself.

> If e2fsprogs-cvs provides and replaces e2fsprogs, thing must be
> OK.  Am I wrong?  I checked all main sections in tyesting and unstable.
>
> All essentials are main and required.

Yes, that's the case currently, but it's not policy that all essential
packages have to be required. If, say, e2fsprogs maintainer wanted to
create e2fsprogs-cvs, he could do so because policy does not forbid it.

We should not confuse reality with policy. Reality is what is. Policy
is what is allowed. Not everything which is allowed actually happens,
and the fact that something does not currently happen does not always
mean it's forbidden.

> > > [...]
> > > "Essential: yes" means that this package
> > > +requires to specify an extra force option to the package management
> > > +system such as <prgn>dpkg</prgn> when removing from the system.  For
> > > +example, <package>libc6</package>, <package>mawk</package>, and
> > > +<package>makedev</package> are "Priority: required" and "Section: base"
> > > +but are not "Essential: yes".
> >
> > However, you still need a --force-depends to remove libc6, which is
> > still "an extra force option", so the example is not very clear.
> > I would choose here more examples like makedev instead of libc6 and mawk.
>
> Hmm.... you have a point.  But that is because we have so many packages
> installed.  If it is minimum install, is this so?

I don't understand exactly what you refer here.

gzip, for example, is essential and depends on libc6. By policy, libc6
should not be essential because it's a library. No matter how few packages
you have installed, you would need a --force option to remove libc6 anyway.
So I would say libc6 is not a good example in either case, regardless
of the number of packages installed.

There are very few packages like makedev which are "required but not
essential and the user is actually able to remove them". As of woody I
can name only mbr, procps, passwd, makedev and modutils.

Those are the ones I would consider good examples of packages which
are truly "required but not essential".

The other required packages are essential-de-facto, because you would
break the dependency of an essential package by trying to remove them.



Reply to: