Is there a way to prevent issues with updating/upgrading packages if not done in a very long time?

[unix_lover]

The problem is that sometimes I install EndeavourOS (even other Arch based distros such as ArchLabs) on some computers and I may very rarely use it. If I want to come back to it and use it, the problem is that when I run:

sudo pacman -Syyu

Suddenly you run in to all sorts of issues. First of all how come this happens?

I know there are ways to fix these issues however is there a way to completely prevent such issues and update it normally, even if the PC was not used in months to years even?

[dalto]

@unix_lover

First of all how come this happens?

There are lots of reasons:

• Package replacements - If you wait too long, you will have a ton of replaced packages. Sometimes packages have been replaced more than once which requires care when handling long updates.
• Removed packages - Packages get removed from the repos sometimes, getting a years worth of those at the same time can cause issues
• Dependency changes - The dependencies of packages change over time. WHen you keep up with updates this won’t be an issue but let it go too long and it can be problematic
• Manual intervention - A couple of times per year, updating requires manual intervention. Again, if you wait a long time you will hit all those problems at once. Also, even if you check on the solutions first, sometimes they don’t apply anymore a years after the fact.
• All of the above - IMO, the biggest issue is that you get hit with all of the above(and probably some things I am not thinking of) at the same time since you waited so long to update.

That being said, it is definitely possible to update an older system. I have done updates on machines that are multiple years old before. It requires a little care and attention as you go through the update process but it isn’t impossible.

@unix_lover

is there a way to completely prevent such issues and update it normally, even if the PC was not used in months to years even?

No. On a rolling release you will always have issues if you wait years between updates. Honestly, you could have the same issues with a fixed release distro if you wait past the end of the life cycle to apply the updates.

If we are talking about months, it just depends how much change has occurred in the intervening period. Sometimes updating a few months at a time won’t be an issue.

[unix_lover]

@dalto

No. On a rolling release you will always have issues if you wait years between updates. Honestly, you could have the same issues with a fixed release distro if you wait past the end of the life cycle to apply the updates.

Is this a problem with Gentoo as well if you happen to know?

[dalto]

Yes, if you let a gentoo system get old past the point where there is an obvious upgrade path it would be even worse.

If you want to have systems you don’t update for a long time a better strategy would be pick a distro with a long support window. For example, Redhat has a 10 year support window so waiting a long time there isn’t a problem. Debian and Ubuntu LTS versions also have decently long support periods.

[freebird54]

Depending on your definition of a ‘long time’, one strategy is to run the Arch archives (see Shift Time here on the site if you don’t know how it works - or Arch wiki) and update to intermediate times in steps until caught up. A nuisance - but likely to avoid massive problems!

Essentially you tell the system to update to a date in the past (using changes in the mirrrorlist, most easily) and pacman -Syyuu for your updates. You can be reasonably sure with 1 month steps, but larger my be OK too - your call.

Below is the post with my little script (and welcome add-on) for making it simpler

Share your alias AND/OR function

This item is more of a script than a function, but it seems to me that it fits here better than in a wiki entry! Essentially, it automates the Arch “Wayback Machine” or, as I have called it ShiftTime What this ‘Machine’ does essentially, is take your system back to the date that you specify - by reverting, or downgrading all the packages that have been updated after that date. I decided I would try to make the script accessible, so here I will describe setting it up as a button in the We…

[jonathon]

@unix_lover

Suddenly you run in to all sorts of issues.

Just to put forward another view, if issues happen “suddenly” then it’s probably not Arch at fault. I’ve updated systems that haven’t been touched for ~12 months without major issues (mainly small tweaks to config files, but nothing pacdiff can’t handle).

So - the question I have is, what issues are you coming across?

On the other hand, if you’re referring specifically to

@unix_lover

other Arch based distros

then “semi-frozen release” distros will regularly have issues with large updates; this is a common theme.

[Orca]

Best is the tabula rasa solution. Download the latest ISO and install new:
https://endeavouros.com/latest-release/

Either that or break out all your unused machines weekly and run updates on them. Don’t be lazy!

[unix_lover]

@jonathon

So - the question I have is, what issues are you coming across?

I wish I remembered, it was a while back.

@jonathon

then “semi-frozen release” distros will regularly have issues with large updates; this is a common theme.

Is this less of an issue with rolling release?

[jonathon]

The more often you update, the fewer packages are updated at once, and the smaller any set of issues will be. For example, if you update one package and it stops working it’s obvious where the issue lies (and it’s fairly easy to resolve). If you update 100 packages at once and five things stop working it’s a considerable amount of extra work to resolve.

However, having a fully-rolling approach means that any issues that are fixed in new packages will appear almost immediately rather than two or more weeks down the line. Recent example, lib32-gtk3. An initial -1 version had conflicting files, -2 was almost immediately released to fix that. If the semi-rolling “update set” contained the -1 version rather than the -2 version it would remain an issue for weeks rather than hours.