Bug#985749: apt: "apt-mark hold" flag lost on package upgrade using --ignore-hold

[Sven-Haegar Koch]

Package: apt
Version: 2.2.2
Severity: minor

Dear Maintainer,

On some of my hosts I have a single or a very small number of packages
that I am only allowed to upgrade with specific procedures, pre-arranged
maintenance window and so on.

But for the rest of the packages I want to install Debian (security)
updates as soon as possible.

"apt-mark hold" sounds exactly like what I want.

I hold the package, and with normal upgrade/dist-upgrade it works
exactly as expected.

But when I then upgrade these single package later using --ignore-hold,
the hold flag is lost afterwards.

The flag is documented in "man apt-get" as

--ignore-hold
Ignore package holds; this causes apt-get to ignore a hold placed
on a package. This may be useful in conjunction with dist-upgrade
to override a large number of undesired holds. Configuration Item:
APT::Ignore-Hold.

So I expect the flag on the package to be ignored for this apt-get
execution, not changed or removed.


Example with docker-ce packages (just because they have multiple
versions in their repository so it was easy to get back to an old
release to show here):

==> Starting with an oudated package version installed

# apt-mark hold docker-ce docker-ce-cli
docker-ce set on hold.
docker-ce-cli set on hold.
# apt-mark showhold
docker-ce
docker-ce-cli

==> Hold flags set

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
docker-ce docker-ce-cli
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

==> A normal dist-upgrade does not touch them, as they are held.

# apt-get install --ignore-hold docker-ce docker-ce-cli
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
aufs-tools cgroupfs-mount | cgroup-lite
Recommended packages:
apparmor docker-ce-rootless-extras
The following held packages will be changed:
docker-ce docker-ce-cli
The following packages will be upgraded:
docker-ce docker-ce-cli
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 66.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
...

==> apt called with --ignore-hold ignores the hold, and upgrades them.

# apt-mark showhold
#

==> But afterwards hold flag is lost!

==> Now whenever the next package release comes out every
==> "apt-get dist-upgrade" will upgrade them, easy to miss
==> and abort when processing a bigger number of hosts.

Greetings,
Haegar



-- Package-specific info:

-- (/etc/apt/preferences present, but not submitted) --


-- (/etc/apt/preferences.d/kde-experimental.disabled present, but not submitted) --


-- (/etc/apt/sources.list present, but not submitted) --


-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2021.1.1
ii gpgv 2.2.27-1
ii libapt-pkg6.0 2.2.2
ii libc6 2.31-9
ii libgcc-s1 10.2.1-6
ii libgnutls30 3.7.1-1
ii libseccomp2 2.5.1-1
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-3

Versions of packages apt recommends:
ii ca-certificates 20210119

Versions of packages apt suggests:
ii apt-doc 2.2.2
ii aptitude 0.8.13-3
ii dpkg-dev 1.20.7.1
ii gnupg 2.2.27-1
ii gnupg1 1.4.23-1.1
ii gnupg2 2.2.27-1
ii powermgmt-base 1.36
ii synaptic 0.90.2

-- debconf-show failed

[Julian Andres Klode]

Control: reassign -1 dpkg

On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> Package: apt
> Version: 2.2.2
> Severity: minor
>
> Dear Maintainer,
>
> On some of my hosts I have a single or a very small number of packages
> that I am only allowed to upgrade with specific procedures, pre-arranged
> maintenance window and so on.
>
> But for the rest of the packages I want to install Debian (security)
> updates as soon as possible.
>
> "apt-mark hold" sounds exactly like what I want.

No, you want to pin them using apt_preferences(5).

>
> I hold the package, and with normal upgrade/dist-upgrade it works
> exactly as expected.
>
> But when I then upgrade these single package later using --ignore-hold,
> the hold flag is lost afterwards.
>
> The flag is documented in "man apt-get" as
>
> --ignore-hold
> Ignore package holds; this causes apt-get to ignore a hold placed
> on a package. This may be useful in conjunction with dist-upgrade
> to override a large number of undesired holds. Configuration Item:
> APT::Ignore-Hold.
>
> So I expect the flag on the package to be ignored for this apt-get
> execution, not changed or removed.

That's the correct behavior - a package has one selection state; and
when you tell it to install something that was hold, that state changes
from hold to install.

Anyway, I think this is a dpkg topic, not an apt one, though I might be
wrong, since we do some temporary state changes, but not sure about the
extend; I think this is really dpkg's decision, though.

The flag ought to be called --unset-hold, but oh well.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

[David Kalnischkies]

On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:

> On some of my hosts I have a single or a very small number of packages
> that I am only allowed to upgrade with specific procedures, pre-arranged
> maintenance window and so on.
>
> But for the rest of the packages I want to install Debian (security)
> updates as soon as possible.
>
> "apt-mark hold" sounds exactly like what I want.

I would think you are better of with apt_preferences as that is intended
to control which packages are allowed to be upgraded (from where). As
that is more powerful in some sense it is also not that easy to handle
though: There is no simple flag e.g. – but using specific files for each
you can disable as needed might be workable.

(It might be an interesting idea to allow preferences to be tagged and
to then to be ignored based on tag selection from the commandline…
that currently doesn't exist at all though and is just a silly random
idea popping into my head as I wrote this mail)

> I hold the package, and with normal upgrade/dist-upgrade it works
> exactly as expected.
>
> But when I then upgrade these single package later using --ignore-hold,
> the hold flag is lost afterwards.

holds are stored by dpkg as a "selection state", which e.g. install or
deinstall are, too, and which will override the old selection state sort
of by design.

It is also this way since the dawn of time, so that is kinda unlikely to
change – resolving this bug might be as "simple" as adding a note that
holds will be (potentially) lost if they are ignored.

Sorry, as that is probably not what you wanted to hear.


Best regards

David Kalnischkies

[Sven-Haegar Koch]

On Mon, 22 Mar 2021, David Kalnischkies wrote:

> On Mon, Mar 22, 2021 at 10:21:59PM +0100, Sven-Haegar Koch wrote:
> > On some of my hosts I have a single or a very small number of packages
> > that I am only allowed to upgrade with specific procedures, pre-arranged
> > maintenance window and so on.
> >
> > But for the rest of the packages I want to install Debian (security)
> > updates as soon as possible.
> >
> > "apt-mark hold" sounds exactly like what I want.
>
> I would think you are better of with apt_preferences as that is intended
> to control which packages are allowed to be upgraded (from where). As
> that is more powerful in some sense it is also not that easy to handle
> though: There is no simple flag e.g. – but using specific files for each
> you can disable as needed might be workable.

This is what I used before, always needing to move the preferences file
away and back into place, which is a pain. And I am missing the nice
note by the "held packages" part in the apt-get output to remind me to
plan the next scheduled upgrade of those.

Right now I work around the loosing of the apt-mark by just running a
cronjob every hour re-applying the mark. Very ugly but works.

> (It might be an interesting idea to allow preferences to be tagged and
> to then to be ignored based on tag selection from the commandline…
> that currently doesn't exist at all though and is just a silly random
> idea popping into my head as I wrote this mail)

Sounds at least like an interesting idea.

Or perhaps just a commandline way to specify additional pin files
outside of those included from /etc/apt/preferences.d directory
automatically. If those specified from commandline are included after
the currently read files you could override "do not upgrade" pins with
it.

> > I hold the package, and with normal upgrade/dist-upgrade it works
> > exactly as expected.
> >
> > But when I then upgrade these single package later using --ignore-hold,
> > the hold flag is lost afterwards.
>
> holds are stored by dpkg as a "selection state", which e.g. install or
> deinstall are, too, and which will override the old selection state sort
> of by design.
>
> It is also this way since the dawn of time, so that is kinda unlikely to
> change – resolving this bug might be as "simple" as adding a note that
> holds will be (potentially) lost if they are ignored.
>
> Sorry, as that is probably not what you wanted to hear.

Thanks.

I think a note in the apt-get manpage on the options (--ignore-hold and
--allow-change-held-packages) would already have helped me a lot - it
took very long to figure out that my problem was indeed loosing the
mark after upgrading the package - as usually the availability of the
next version of a marked package happens weeks or months later.

And when you discover the mark missing on a dist-upgrade call then, you
mostly think "I thought I set it, did I really also on this server?" :)

Never even got the idea that the hold would not be supposed to
survive, neither from apt-get nor from apt-mark manpages.

c'ya
sven-haegar

--
Three may keep a secret, if two of them are dead.
- Ben F.

[Guillem Jover]

Control: reassign -1 apt

Hi!

In dpkg this got clarified with bug #926472, I've just pushed a commit
to dpkg git HEAD to further clarify a confusing wording in the man page
for the --force-hold description, but otherwise I think the stuff in
the «Packages selection states» subsection should be clear enough
already.

Given that you request improvements to the apt documentation, I'm
reassigning back.

Thanks,
Guillem