On Mon, 22 Mar 2010, David Kalnischkies wrote:
> I will further enlarge my example: Imagine you have a stable system with
> perl-base essential and you install a perl application from testing which
> also pulls in a newer non-essential perl-base. Remove the perl application
> now and run autoremove (aptitude will do this automatically by default) -
> APT will remove perl-base as it is not essential and no (installed) package
> depends on it (explicitely). That you break even parts of dpkg with this
> move is your personal problem then, i guess?
No, the situation you describe would be our problem as system integrators
for allowing such thing to happen.
As I said, apt is not the only install method, so if we are really
serious into supporting partial upgrades (and I think we are), we
could probably not drop the essential status of any given functionality
in just one release without a transition period in which we add
required dependencies on the package which is to become non-essential,
even it it's still essential.
And apt should not try to solve that problem in just one release, as
the user might be using something else.
> Think also about the situation in between the upgrade - essential packages
> can't be removed - but other packages can be removed in between an
> upgrade if required: If your system is in the middle of the upgrade, is
> the package now essential or not - and will a {post,pre}rm scripts need it?
Supporting partial upgrades is the reason we will never be able to
drop an essential package in just one release. Once we realize we need
two releases, partial upgrades would not be a problem.
Following your example, if we want to make perl-base non-essential, then
we would first make a stable release in which every package which uses
its functionality has an explicit depends. After such release is made,
we can drop the essential flag in the next one. Partial upgrades, with
or without apt, would then always work.
> > 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.
>
> So your hurd kvm install was broken: packages which require the missing
> essential package can't use it and you complain now that APT tries to fix
> this for you?
No, not exactly. Note that whenever I spoke about apt-get "fixing" the
system I have always used quotes around the word :-)
The package was sysvinit and the Hurd uses a different boot method,
and in fact, it booted just fine wihout sysvinit being installed.
I have still to check with the Hurd people whether sysvinit should be
really essential on this architecture or not.
The point is that this package was not present in the initial install,
and everything worked fine, so I feel that apt-get was not doing the
right thing by installing it automatically, without giving a warning,
and without even telling me "installing this because it's essential".
> > 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.
>
> Why APT need to specifically ask for installing the essential packages?
(Note: By essential I understand you mean "essential and required
packages" here).
Because they are already installed by default, and they are never
uninstalled "by accident". Considering how difficult is to remove
an essential package, if you have a system in which some essential
package is not installed, one likely possibility that we should not
discard is that the user wanted it that way.
> Essential packages are considered to be always installed as no package
> need to depend on it explicitly. So if the package is not installed you have
> a broken dependency for theoretical every package - and as APT doesn't
> like broken dependencies it will fix it. Would you also complain if the
> package would be a "normal" dependency? Essentials are dependencies,
> they are just not written down explicitly?
Not every implicit dependency on an essential package is a *package*
dependency in the dpkg sense, i.e. of the type that would have to
become explicit if the package becomes non-essential.
For example, if my root partition is in ext2/ext3 format, then e2fsprogs
is essential in my system. It could well be that no package depends on it,
and no dependencies would have to be added if it was to lose its essential
status.
OTOH, if none of my partitions are in ext2/ext3 format but something
completely different, and I remove e2fsprogs because it's not essential
in my system, why in earth should e2fsprogs be forced to be installed
again and again and again?
While it is true that there might be implicit dependencies on
essential packages, it is also true that there might be none.
> >> 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?
>
> I suspect the e2fsprogs-foo package is from you as i haven't such a package
> available, that is why i added this remarks.
Ah, I see. We would have to live with the time window in the
e2fsprogs-foo case. That would not be too bad, as e2fsprogs is mainly
used at boot time.
> I could have also added that some discussions are ongoing to drop
> e2fsprogs from essential, but i guess you already know that.
I didn't know as I don't follow the lists closely, but considering how
many different filesystems are there and our aim to be universal,
that's not surprising.
BTW: This is the perfect example, really. We don't really need
e2fsprogs to drop its essential flag, we would just need apt-get
(and friends, if any) not to install essential and required packages
"just because they are essential and required".
We could well tell debian-installer to install e2fsprogs if any of the
partitions in a newly installed system is in ext2/ext3 format, or not
if that's not the case.
Then e2fsprogs would only be installed on systems really needing it.
In those systems, the package would be difficult to remove, just as it
happens now, but systems not using it would not be forced to install it.
See why I say that "Essential: yes" means "do not remove me easily", not
"install me if I'm not installed"?
The interpretation of "Essential: yes" in policy for which I'm
advocating here would solve the essentialness of e2fsprogs in a clean
way: It's only truly essential if you have it installed to begin with.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
