Pacman: how to always update certain packages to a former version?

sharethewisdom · 2019-03-01 10:39:20

I'm looking for a robust way to avoid certain packages to be up to date, as I want them to synchronize it a former (typically next from latest) version (i.e. slow down the rolling release). I guess those versions don't linger around on the remote repos.

The solution will probably be to add the packages to IgnorePkg/IgnoreGroup, and create a shell script to just download them and update to the former versions from the cache. Could this be done with ALPM hooks? Is it clear what I'm asking?

Last edited by sharethewisdom (2019-03-01 10:40:27)

Trilby · 2019-03-01 14:04:43

It's clear what you are asking, but not why you would want to do this. On occasion there many be a reason to pin a package at a specific version, but even then this is risky. But why on earth would you just want to lag behind on some packages? Which packages specifically?

This would be unsupported, and will likely cause all sorts of problems.

Alad · 2019-03-01 14:31:30

Arch provides no facilities whatsoever to support partial upgrades. In particular, the vast majority of packages have no version information for dependencies, and deriving from the consistent state of the repositories may result in arbitrary breakage.

Your options are to either

1. not use Arch
2. use archive.archlinux.org to fix all packages to a fixed date

You could also try to automatically rebuild "old" versions when the repository one is updated, e.g. for soname bumps. This is likely to be a greater time-investment than the above options, though.

schard · 2019-03-01 16:02:30

sharethewisdom wrote:

[...]I want them to synchronize it a former (typically next from latest) version (i.e. slow down the rolling release).

This does not "slow down" the rolling release as you will still get updates with the same frequency, just always being one version behind.
Moreover I agree with the previous commentators.

Last edited by schard (2019-03-01 16:02:53)

Trilby · 2019-03-01 17:54:11

What you can do if you really want to "slow down" the number of updates is just not update so often. Do full upgrades, but only every month or so.

Generally archers advise more frequent updates, but updating monthly is certainly fine (just watch for any relevant news items that might prompt you to do an early update from time to time).

But in any case, this is why I'm curious why you'd want to do this. What is your end goal? This sounds a bit like an X-Y question.

sharethewisdom · 2019-03-07 15:01:01

Trilby wrote:

What you can do if you really want to "slow down" the number of updates is just not update so often. Do full upgrades, but only every month or so.

I'm looking to use a Dynamic reverse proxy cache using nginx. I obviously don't want partial updates, but I do want anything that can be updated, to be updated ASAP while resolving dependencies based on, say the previous kernel version.

After a period of testing, I ultimately want to run some sort of autoupdate system within someone's LAN, while authoring it through ssh and receiving news about manual intervention trough email.

Trilby · 2019-03-07 15:18:19

So you want to be able to test updates on one machine before deploying those updates to all the other machines?

If so, you wouldn't want those other machines to just stay one version behind current, they'd have to stay one version behind what you are currently testing. Some packages are rarely updated, some very frequently. If package A goes from version 1.2 to 1.3, then while you are still testing 1.3 (and the other machines are still using 1.2) it is updated again to 1.4, you'd not want those other systems to ugrade to 1.3 right away as you're still testing that one, right?

So just update the testing machine, test everything out for a bit, then when you are satisfied with the state of that machine, update all the other machines from the test-machine's package cache.

But still note I'm still stuggling to clarify the X-Y question here. Initially you had some goal, and you thought updating to the penultimate version of packages would be the way to acheive that unstated goal. Now, you say you are "looking to use ..." a specific approach to accomplish your goal. But tell us about your actual end goal. I've inferred above what it *might* be: testing packages on one machine before deploying then to others.

Last edited by Trilby (2019-03-07 15:28:36)

/dev/zero · 2019-03-07 22:09:28

Are you sure Arch Linux is the best choice for what you're trying to do?

One of the key strengths of Arch Linux is exactly that it is rolling release. Arch Linux is most stable when it is getting updated with high frequency: at least once per week, but daily is even better. This makes it an excellent choice for a daily driver on a laptop or personal workstation, but it's not necessarily ideal for all imaginable scenarios.

Different distros exist for different reasons. It sounds a bit like you're trying to procrusteanise Arch into a niche where perhaps Debian or a BSD feels like a better fit.

sharethewisdom · 2019-03-08 21:47:56

Trilby wrote:

So just update the testing machine, test everything out for a bit, then when you are satisfied with the state of that machine, update all the other machines from the test-machine's package cache.

I'll do that.

Trilby wrote:

Initially you had some goal, and you thought updating to the penultimate version of packages would be the way to achieve that unstated goal.

Thanks for your patience. My goal is simply to decrease the likelihood of installing unstable software, while maintaining a high frequency of rolling release updates (with delta downloads).

I teach new linux users the joy of manually updating a minimal system using pacman. But I don't want them bothered to remember to still download the latest linux package when linux in IgnorePkg. I know that the question about specifying a version was asked before. Lowering the update frequency does not solve problems when programs need to be fixed, except perhaps if I could update right before a version bump of the kernel package, or right after versions of packages that include bugfixes to match the current kernel.

/dev/zero wrote:

Arch Linux is most stable when it is getting updated with high frequency: at least once per week, but daily is even better. This makes it an excellent choice for a daily driver on a laptop or personal workstation, but it's not necessarily ideal for all imaginable scenarios.

The 8 years before my recent kernel issues I had no real problems with the rolling release. I indeed try to update my Thinkpad T400 twice a week from the official repositories. I've been adding the linux package to IgnorePkg because I suspect that the number of kernel panics on my Thinkpad T400 has been increasing the last two years. I've considered using the linux-lts package and I noticed that downgrading linux often solved issues. My real problem here is possibly that these issues are related to CPU tunings or who knows, bad Intel microcode.

Trilby · 2019-03-09 00:23:42

If this is really just for the kernel (and the few associated packages that actually have a versioned dependency on the kernel) then you'd be better of with a custom repo placed at the top of all the machines pacman conf. You can supply the custom repo with whichever kernel version (and nvidia or other driver that is needed) that you have tested. Then let all the machines upgrade normally, but they'll pull their kernel from that repo.

FWIW, I use Thinkpads, and have never had any problems like what you describe. Have you applied the microcode updates? (i.e., installed the package and added the img to your bootloader's initramfs line).

EDIT: wait, I had some when I was still trying to use the xf86-video-intel driver, that's not what you are using is it?

Last edited by Trilby (2019-03-09 00:24:44)

sharethewisdom · 2019-03-09 20:51:07

I have intel-ucode and the bootloader configured to use the image.

Trilby wrote:

EDIT: wait, I had some when I was still trying to use the xf86-video-intel driver, that's not what you are using is it?

Thanks for pointing out, apparently I have it installed for no reason.

This is my /proc/cmdline

BOOT_IMAGE=/boot/vmlinuz-linux cryptdevice=UUID=3d17c5b4-a603-4600-9f36-c598a7da783e:root root=/dev/matrix/rootvol resume=/dev/matrix/swapvol rw enforcemodulesig=1 sysrq_always_enabled=1 systemd.journald.forward_to_console=tty1 console=tty1 pause_on_oops=10 loglevel=4 fbcon=scrollback:128k acpi_osi=Linux intremap=off iomem=relaxed video=SVIDEO-1:d

Is the iomem=relaxed kernel parameter problematic? I remember needing that to prevent warnings (I use libreboot). I always try to learn from the journal after a panic or an oops, but I rarely understand what's going on. It sometimes craches while playing back certain video files with mpv, but infrequent.

The idea of a custom additional repo works for me, in fact I already use one locally. But I'm not sure I want inexperienced new users to have to configure all that. Maybe there's another use-case for penultimatility if not: never mind, I realize that there are a number of options besides IgnorePkg, and in the spur of the moment I guess I was feeling clever. cheers.

Last edited by sharethewisdom (2019-03-09 23:45:42)

ivanmlerner · 2019-03-09 22:03:00

If this is for the kernel only (sorry, I'm kind of a newbie, so maybe this doesn't make sense), wouldn't it make sense to just use the LTS kernel?

sharethewisdom · 2019-03-18 13:46:32

ivanmlerner wrote:

If this is for the kernel only (sorry, I'm kind of a newbie, so maybe this doesn't make sense), wouldn't it make sense to just use the LTS kernel?

Hi, sorry for the late reply. Yes it does, and I sometimes do, but I prefer a backdated mainline version for a number of reasons. Some of these are arguments outlined in this video. A few times I attempted to compile the kernel myself, but in order for me to stay current this meant that I need to spend precious time on a machine with more memory etc.

Anyway I always have both linux and linux-lts installed on my laptop because I sometimes couldn't boot otherwise. I locked down grub. I don't always carry bootable flash media with me, and I don't know my complicated random grub password by heart which I need to access a command prompt or a submenu. This is the only way for me to access anything else than the signed stuff to boot from. Booting from linux-lts is usually fine when I experience a kernel panic with the linux package.

Arch Linux

#1 2019-03-01 10:39:20

Pacman: how to always update certain packages to a former version?

#2 2019-03-01 14:04:43

Re: Pacman: how to always update certain packages to a former version?

#3 2019-03-01 14:31:30

Re: Pacman: how to always update certain packages to a former version?

#4 2019-03-01 16:02:30

Re: Pacman: how to always update certain packages to a former version?

#5 2019-03-01 17:54:11

Re: Pacman: how to always update certain packages to a former version?

#6 2019-03-07 15:01:01

Re: Pacman: how to always update certain packages to a former version?

#7 2019-03-07 15:18:19

Re: Pacman: how to always update certain packages to a former version?

#8 2019-03-07 22:09:28

Re: Pacman: how to always update certain packages to a former version?

#9 2019-03-08 21:47:56

Re: Pacman: how to always update certain packages to a former version?

#10 2019-03-09 00:23:42

Re: Pacman: how to always update certain packages to a former version?

#11 2019-03-09 20:51:07

Re: Pacman: how to always update certain packages to a former version?

#12 2019-03-09 22:03:00

Re: Pacman: how to always update certain packages to a former version?

#13 2019-03-18 13:46:32

Re: Pacman: how to always update certain packages to a former version?

Board footer