On Sun, Dec 18, 2022 at 06:08:57PM +0100, Johannes Schauer Marin Rodrigues wrote:
> Quoting David Kalnischkies (2022-12-18 17:18:28)
> > On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
> > > Then there is "e2fsprogs", which apt seems to treat as if it were
> > > an essential package:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587
> >
> > As Julian explained, it is considered "essential" because the maintainer
> > said so. If you don't think e2fsprogs should be considered "essential"
> > for a system it is installed on please talk to the maintainer.
> >
> > Sure, the package is not (anymore) really "Essential:yes", but 'apt'
> > isn't either and will print the same message anyhow. I don't think it
> > would be a net-benefit for a user to invent words for different types of
> > essentialness in apt because in the end you either know what you are
> > doing while removing a somewhat essential package and continue or you don't
> > know what you are doing and (hopefully) get the hell out.
>
> would it be so difficult to cater to both kind of users? For those who do not
> know the terminology, using the word "essential" is probably fine. But for
> those who do it's confusing. Why can apt not say something like:
>
> WARNING: The following packages will be removed. Apt considers them essential
> because they are marked as Priority:required. This should NOT be done unless
> you know exactly what you are doing!
This is objectively wronger™ through: prio:required packages are not
considered essential by apt. Most are for other reasons, but priority
has nothing to do with it. The same "you are about to remove an
essential package" (paraphrased) message is shown for:
- packages marked as Essential:yes in ANY [native] version known to apt
(if you don't modify that behaviour with pkgCacheGen::Essential)
- packages marked as Important:yes/Protected:yes in ANY [native] version
(surprisingly Julian has not added a option here… mhhhh)
- binary packages listed via the pkgCacheGen::ForceEssential option,
(the list can NOT be empty, it will default to "apt")
- binary packages listed via the pkgCacheGen::ForceImportant option
(empty list by default)
- packages that are (pre-)dependencies of the other points if that
package is removed, too.
(Note that the mentioned options do work only if you generate a cache
and also 'taint' that cache meaning that a reused cache later without
those options will still behave as if they were given.
You have been warned.)
The later ensures that you can e.g. change awk providers, but be smacked
with a huge clue bat if you remove the last provider, even if that
happens to be the prio:optional gawk which as a package itself doesn't
look like it would be essential in any way without going into a lot of
details completely lost on most apt users (for good reason, after all,
if you wanted to know all that, you would probably do dpkg by hand or
at least maintain apt… and nobody wants to do THAT, am I right…)
Also: "marked as …" – by whom? If you say it like that, a user might
think they did; like they marked some package to be held back for
example and that marking can (should?) be removed.
The problem in showing something different for Essential:yes (derived)
and Protected:yes (derived) essential packages is that the difference
between the two is marginal from apts POV: Essential:yes has to work in
unpacked state, but that is a dpkg-level thing to worry about and hardly
a real concern for the general public. Just like the reduced install
order requirements in general.
Okay, things don't need to depend on Essential:yes packages if they use
them, but that tends to be the case for Protected:yes as well as not
that much really "uses" an init system for example. Other distros slap
Protected:yes on high-level meta packages like 'gnome'. Nobody depends
on that either.
All the two really do in terms of apt (front ends – the message is apt
specific, but the fields aren't so it would be kinda nice if terminology
could be reused by other front ends if they so choose) is making it
a pain to remove them, but being too upfront about that has its problems
as well as it naturally leads to the question "why?" which apt preempts
with the ultimate hammer: Its essential for the system as the individual
reason for each package might even be distro-specific. Users usually
don't question that.
It's a lie. Heck, it might even be deception. But the truth hurts more:
"Heh, you are a great user, you really are, but you know, no offense,
but I am a computer program on a device you (think you) own and should
probably be able to do whatever you want to do with it, but there are
other people who are not you who think you might be an idiot, so they
said I should not let you do that and I trust them because they… well,
how do I put it so that even you understand it… they live in the cloud,
yes? So, anyway, are you like, absolutely positively sure about this?"
> > "It may". Well, certainly apt won't autoremove it. Like a lot of other
> > packages it wont even through they aren't essential or protected or
> > whatever… ("just" prio:required is enough for example). They are not not
(As that might be the source of the prio-confusion: Note that I said
"autoremove" as I assume that is what deals with the removal of build
dependencies after a build in non-ephemeral chroots. That is an
operation which is a lot more conservative than a "(manual)remove"
spelled out directly by a user)
> > Due to that, you are now presented with:
> > | E: Removing essential system-critical packages is not permitted. This might break the system.
> >
> > See? "essential" again and even "system-critical" at that.
> > It is all a lie of course. Nobody really needs an init system, much less
> > some silly metapackage for it, as long as there is /bin/sh and a keyboard.
> > I should make a video about it to – essentially – become famous & rich…
>
> Dammit, and now you wrote that one can use in a public forum that it's possible
> to add --allow-remove-essential! Think of the children!
I know, I know, I am a monster.
As the same public forum is still discussing fortune-off I do question
what you consider an appropriate place for [your] kids to read through.
Also: I "wrote", that means someone would need to "read" it.
That violates the premise of "video, or it didn't happen". 😉
> > Btw, apt also has behaviour specifically for sbuild: 'apt-cache show
> > mail-transport-agent' has a zero exitcode even through that makes no
> > sense at all apart from not making (some?) sbuild versions explode.
> > You are welcome. I hate it.
>
> Errrr... lets change that. What's the problem in sbuild?
Honestly? No idea and probably not the right place to talk about it.
I have just very faint memories of writing decade old hotfixes:
apt (0.7.26~exp12) experimental; urgency=low
[…]
* cmdline/apt-cache.cc:
- use Notice instead of Error in the CacheSetHelper messages
for compat reasons. Otherwise tools like sbuild blow up
- return success in show if a virtual package was given
[…]
-- Michael Vogt <mvo@debian.org> Fri, 30 Jul 2010 11:55:48 +0200
or:
apt (0.8.15.8) unstable; urgency=low
[…]
* cmdline/apt-get.cc:
- output list of virtual package providers to c1out in -q=1
instead of /dev/null to unbreak sbuild (LP: #816155)
[…]
-- Michael Vogt <mvo@debian.org> Wed, 14 Sep 2011 12:08:25 +0200
I just thought the implied "do they care about sbuild?" deserved an
example of how apt tends to bend over backwards, even for sbuild.
Likely not the best one I could have picked in hindsight.
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature