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.
> This sort-of breaks sbuild when using an ordinary chroot (not overlayfs),
> because after building a package needing e2fsprogs, it may not be removed
> and it's kept in the chroot.
"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
irremovable through. It might just be a little harder to remove them
than to install them. Heck, some people believe its far easier to start
vim than to exit it.
> I think apt authors did not think that apt is used by sbuild to
I think (the few) apt authors deal with way too many users with way too
many (sometimes mutually exclusive) ideas of how it should behave:
> build packages. Here we would need some interface like SUDO_FORCE_REMOVE=yes,
> or maybe just stop doing anything at all with the Important:yes flag.
Ironically, one of the selling points for Protected:yes (that is how the
field ended up named which dpkg is supporting by now) was that it allows
to shrink the essential set (e2fsprogs even being an example) as there
is a non-empty set of people who believe users do incredibly dumb things
if you give them the option to.
I mean, we got practically bullied into replacing the "Do as I say!"
prompt with a semi-hidden cmndline flag (--allow-remove-essential)
because some wannabe YT star yolo'ed the prompt ending in misery and
somehow that was framed as our fault by everyone as we didn't show the
appropriate meme-gif (rendered with caca) to make them understand
without reading [sorry, not sorry. I am not even exaggerating that much].
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…
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.
So, long story short, apt features and behaviour are very seldom done
because we are bored and had nothing better to do. It is far more common
that it was heavily requested to be that way for $REASONS. Sometimes its
even the same $REASONS you have for disliking it. Users are the worst,
I said it here first. But no problem, there usually is an option to
change anything in apt. If not, we can usually add it.
Just don't assume that the behaviour you prefer will be the default.
We have a strong tendency to make everyone unhappy.
(I should know, I never get what I want.)
Best regards
David Kalnischkies
P.S.: You thought we are surprised by sbuild using apt? Sorry, but you
are up against ISO building needing 'apt-cache depends' output previously
unknown even to the CD team itself (https://bugs.debian.org/218995#54)
(yes, it is a decade old. It's still my favorite). Try harder.
Attachment:
signature.asc
Description: PGP signature