User talk:NetSysFire

From ArchWiki

Installing outdated packages without refreshing

Hi! I noticed you have reverted (and here) my edits, commenting "using the archive as a way to avoid a full system update is unsupported". Sorry I don't clearly understand your comment, but

-- if you mean:

No, my tips do not mean partial upgrade. It in fact gives the opportunity to not upgrade the system, but still able to add new (but possibly outdated so cannot be fetched from normal mirrors) packages into their system.

The effect is like this; if one day you -Syu the last time and swear never to -Syu anymore, then the system is like pinned to the version of that day. You can still -S packages of that day's version, but no latest versions. Then another day you eat your words and -Syu again, the system bumps its version to that day. No partial upgrades!

-- Or if you mean:

  • Do not use old softwares; one should actively keep up with the latest Arch version --

Well, not to say there are ones (like me) too lazy to frequently -Syu. There are scenarios, like some mentioned here, when one

  • cannot risk breaking the system to -Syu,
  • need a package, but -S just throws many 404, and
  • have read Partial upgrade is unsupported, afraid of -Sy then -S.

I hope my tips could make things easy.

-- Or if you mean:

  • The ALA is discouraged to use as a normal or fallback repository mirror (due to some technical reasons? network pressure? etc.) --

I apologize not knowing this, but I haven't found where it is mentioned. Maybe better note this in ALA?

Hoping to hear from you. Thanks! E792a8 (talk) 16:39, 3 November 2024 (UTC)Reply

Your edit involved mixing the ALA with up-to-date mirrors. This does lead to partial upgrades - you may retrieve newer package versions from an updated mirror using pacman -Syu, but still have an old ALA entry at the bottom that points to the date of a previous -Syu.
Issues then arise when a package was removed from the repositories, a version was not increased monotonically (downgrade without epoch bump), or - more commonly - your mirror is offline or out-of-sync and fails to download the correctly-versioned package. See the warning in Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date]. The only plausible approach here is to only use the ALA entry as your mirrorlist. -- Alad (talk) 18:53, 3 November 2024 (UTC)Reply
Even using the archive as the only entry is not robust enough to be "supported" because of the way the Archive is managed. Packagers release new packages atomically into the main repo, but the synchronization from the repo to the archive is not atomic - if a new package is released during the archive synchronization, it might sync the new database and old package, or vice versa. Right now the archive and repos are located on the same server so this window of opportunity may be quite small, but they will be split in the future. — Lahwaacz (talk) 05:50, 4 November 2024 (UTC)Reply
Well, the same argument holds unless you're using the Tier 0 mirror (only for staff)... a mirror may not be synced completely, but can still be used with pacman. -- Alad (talk) 13:22, 4 November 2024 (UTC)Reply
The difference is that a mirror will eventually sync and re-running pacman -Suy later will fix the "glitch", whereas a daily archive stays the same all the time. But the OP pointed out that this was not used at all so 🤷 Lahwaacz (talk) 13:39, 10 November 2024 (UTC)Reply
Thanks for reply! But sorry I'm still confused by some of your explanations - like what means "an old ALA entry at the bottom", just the Server= line in mirrorlist? And how does it "point to" a date? - I think things shouldn't be that complicated...
Note that my tips use the ALA's /packages/.all feature, not a date-fixed /repos directory. This .all directory does not provide "reponame.db" database files, but only "package-version.pkg.tar.zst"s. It is just a place to fetch packages, but the database is always (and only) refreshed from the normal mirrors.
For the cases you mention, I think only that a version is not increased monotonically matters; but this itself is a problem for package maintainers. For other cases, since the local database remains unchanged (or synced with the normal mirrors) and consistent, -S should always fetch the package of the version recorded in the database. The only difference is: originally the fetch may fail; but with a fallback ALA /packages/.all, it will succeed. E792a8 (talk) 13:17, 4 November 2024 (UTC)Reply
Pacman removes a mirror from its pool after several errors, including 404. So if you are out-of-sync long enough, you will be downloading most of the packages from the archive rather than any other mirror, even if most of the selected packages are still up-to-date and available on mirrors. This is not nice, you would need something similar to CacheServer but with lower priority than Server. — Lahwaacz (talk) 13:50, 10 November 2024 (UTC)Reply