Debian Bug report logs - #1030020
apt: Conditional way to automatically uninstall Protected packages due to Build-Conflicts

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: submit@bugs.debian.org

Subject: apt: Conditional way to automatically uninstall Protected packages due to Build-Conflicts

Date: Mon, 30 Jan 2023 12:03:14 +0100

Package: apt
Version: 2.5.5
Severity: wishlist

Hi!

On a thread on debian-devel, Adrian Bunk brought up the potential
problem of packages with a Build-Conflicts against a
«Protected/Important: yes» package. To me it makes sense that the
tooling should be able to cover this theoretical problem automatically,
when the build is happening on a discardable system (such as in a chroot
or an ephemeral VM). On a practical note, I think I'd find upsetting
if the particular example brought up (e2fsprogs) was to be added
as a Build-Conflicts of any package, as that pretty much means it
would be unsafe to build such package on your main system if your
filesystem is extN, and IMO that package would deserve a bug report.

I checked the code and I find in apt-pkg/deb/dpkgpm.cc the
config variable pkgCacheGen::Protected being used, but I'm not sure I
understand how it is intended to be used? The code returns true for
"none" and "native" and when the "Important" flags is not-zero, but
«doc/examples/configure-index» also mentions an "all" value which
does not seem to be handled here? Shouldn't the "none" mean to return
false?

If this is already supported by that option I'd request documentation
for it, or otherwise support for a similar option to control this
would be nice. Then a build-driver such as sbuild or pbuilder could
disable that option when and iff it knows it is driving the build
inside a discardable system.

Thanks,
Guillem

Message #8 received at 1030020@bugs.debian.org (full text, mbox, reply):

From: Johannes Schauer Marin Rodrigues <josch@debian.org>

To: 1030020@bugs.debian.org, Guillem Jover <guillem@debian.org>

Subject: Re: Bug#1030020: apt: Conditional way to automatically uninstall Protected packages due to Build-Conflicts

Date: Tue, 31 Jan 2023 10:00:57 +0100

[Message part 1 (text/plain, inline)]

Hi,

Quoting Guillem Jover (2023-01-30 12:03:14)
> On a thread on debian-devel, Adrian Bunk brought up the potential problem of
> packages with a Build-Conflicts against a «Protected/Important: yes» package.
> To me it makes sense that the tooling should be able to cover this
> theoretical problem automatically, when the build is happening on a
> discardable system (such as in a chroot or an ephemeral VM). On a practical
> note, I think I'd find upsetting if the particular example brought up
> (e2fsprogs) was to be added as a Build-Conflicts of any package, as that
> pretty much means it would be unsafe to build such package on your main
> system if your filesystem is extN, and IMO that package would deserve a bug
> report.
> 
> I checked the code and I find in apt-pkg/deb/dpkgpm.cc the
> config variable pkgCacheGen::Protected being used, but I'm not sure I
> understand how it is intended to be used? The code returns true for
> "none" and "native" and when the "Important" flags is not-zero, but
> «doc/examples/configure-index» also mentions an "all" value which
> does not seem to be handled here? Shouldn't the "none" mean to return
> false?
> 
> If this is already supported by that option I'd request documentation
> for it, or otherwise support for a similar option to control this
> would be nice. Then a build-driver such as sbuild or pbuilder could
> disable that option when and iff it knows it is driving the build inside a
> discardable system.

if apt offers such an option, I'll add it to sbuild immediately.

Thanks!

cheers, josch

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 1030020@bugs.debian.org (full text, mbox, reply):

From: David Kalnischkies <david@kalnischkies.de>

To: Guillem Jover <guillem@debian.org>, 1030020@bugs.debian.org

Subject: Re: Bug#1030020: apt: Conditional way to automatically uninstall Protected packages due to Build-Conflicts

Date: Tue, 31 Jan 2023 14:27:06 +0100

[Message part 1 (text/plain, inline)]

On Mon, Jan 30, 2023 at 12:03:14PM +0100, Guillem Jover wrote:
> I checked the code and I find in apt-pkg/deb/dpkgpm.cc the
> config variable pkgCacheGen::Protected being used, but I'm not sure I
> understand how it is intended to be used? The code returns true for
> "none" and "native" and when the "Important" flags is not-zero, but
> «doc/examples/configure-index» also mentions an "all" value which
> does not seem to be handled here? Shouldn't the "none" mean to return
> false?

pkgCacheGen::Essential is affecting the generation of the binary cache.
Specifically, it tells the code to ignore the flag it parsed from the
file in certain conditions and not mark the package essential in the
cache – so that later apt code/runs believe the package is not marked
essential at all.

The code you found is preparing the command line for dpkg and that
of course doesn't know what apt believes, so for certain values apt
has to tell dpkg for all packages that dpkg is allowed to remove
essential packages.

- "all" is the default and keeps them all (aka ignores nothing).
- "native" only marks :native or :all packages
- "installed" only gives packages which are installed the flag
- "none" ignores it for all, so no package is essential

As we talk removals here we have to allow dpkg for all packages in the
native/none case as we don't know if we have "forgotten" the flag for
some packages. In the "all" case we haven't and in "installed" we
haven't for anything which matters (= we aren't removing not installed
packages after all), so those can rely on the info from the binary
cache.


But wait, you said pkgCacheGen::Protected… which intuitively should
behave in the same way, but isn't handled in the same place essential
is in apt-pkg/deb/deblistparser.cc. mhhhhh, I wrote the essential code
(there, not the code you found actually) a long while ago but was not
involved in the protected feature, so that could be intended in some
way I don't foresee yet, but I suppose it was just forgotten.
It is a rather esoteric feature after all.


> If this is already supported by that option I'd request documentation
> for it, or otherwise support for a similar option to control this
> would be nice. Then a build-driver such as sbuild or pbuilder could
> disable that option when and iff it knows it is driving the build
> inside a discardable system.

So, pkgCacheGen::Essential exists but isn't really documented except on
a need-to-know basis and somewhere in the multiple-duplicates collection
of bugs asking apt to behave a certain way with essentials.

The reason is that it is hard to use: you need to provide it to the
command which generates the binary cache, which is stored on disk for
later commands to reuse as long as it remains valid & petty dangerous
as apt will e.g. easily come to the conclusion that removing coreutils
is acceptable because nothing really depends on it…
While most users who demand such an option are more of the type:
I want to remove this previously essential package (diff) which is now
a transitional package (diffutils) but don't want to remove the old
sources.list entry and I am really annoyed that apt reinstalls a package
which is essential for an old release I have in my sources… those users
are prime candidates for shooting themselves in the foot while demanding
support as its an officially documented option.


Anyway, you can get away with Build-Conflicts on Protected packages
a lot easier with (partially) documented options:

--allow-remove-essential -o APT::Get::Allow-Solver-Remove-Essential=true

The first gets you past the error which used to be "Do as I say!" and
the second is for the internal apt resolver (and relatively new¹). If
another resolver is used you might need to use options specific to it
(or not, if it doesn't care about the field). That isn't specific to
build-dependencies either, its what you need in general while removing
them (indirectly – the first is enough if you mention the package
explicitly on the command line directly) in all cases.

Yes, essential and protected are given the same treatment here.
An equivalent just effecting protected seems not to exist.


So, in summary, I think the solution to this bugreport might simple be
to have the former flag also enable the later config option and perhaps
mention in the documentation that this flag also effects protected.

The semi-alternative would be to add also an --allow-remove-protected
but I am not sure this is actually needed/a good idea. You have to be
careful with either if your system is important and if your system isn't
you are somewhat likely to provide both options together to apt anyhow
just to be sure…


Best regards

David Kalnischkies

¹ 891efe3b201a104445ea723a3a5b9b434a78c364 (Wed Nov 17 2021)

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.