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.
