You are not logged in.

#1 2021-02-02 10:59:39

Ferdinand
Member
From: Norway
Registered: 2020-01-02
Posts: 38

[SOLVED] Pacman mirrorlist optimalization horror

I just tried out a workflow to keep my mirrorlist optimized:

1. Generate my mirrorlist at https://archlinux.org/mirrorlist with mirror status enabled, to only include up to date mirrors
2. Copy & Paste the mirrorlist into /etc/pacman.d/mirrorlist.generated
3. Run sudo sed -i "s/^#Server/Server/" /etc/pacman.d/mirrorlist.generated to enable all the newly generated mirrors
4. Run sudo sh -c "rankmirrors -n 6 /etc/pacman.d/mirrorlist.generated > /etc/pacman.d/mirrorlist" to choose the 6 speediest mirrors for my mirrorlist
5. Run pacman -Syyuu to refresh the pacman database and ensure my installed packages correspond to the versions offered by the new mirrorlist

Now, when I did the last step, I got warnings for all my installed packages that they were newer than the packages in the mirror and, thankfully, an error: "failed to prepare transaction (could not satisfy dependencies)" - so it didn't downgrade everything tongue

Then I tried sudo pacman -Syyu instead, with the same result, except no error; just a "there is nothing to do".

And so I took back the old mirrorlist, which I had kept, and all is well again.

But what the heck was that all about? Shouldn't the generated list contain only up to date mirrors?
And choosing the six fastest from that list should give me the fastest up-to-date mirrors - so what's with the downgrades?

I feel a bit silly, so guess I probably am smile?

Last edited by Ferdinand (2021-02-02 14:38:34)

Offline

#2 2021-02-02 11:42:01

mpan
Member
Registered: 2012-08-01
Posts: 641
Website

Re: [SOLVED] Pacman mirrorlist optimalization horror

Consider community/reflector.

Do not -Syyuu: it only causes pointless load to mirrors. If anything, just -Syu: either your database is newer than mirror’s — in which case nothing happens — or your database is newer than mirror’s — in which case a normal update takes place. One of the rare cases when changing mirrors may require -Syyuu is if you’re receiving 404s during -S pkgname due to the mirror being outdated with respect to your database. But I suppose you do not change mirrors to use one that is older than your current one, right?


Sometimes I seem a bit harsh — don’t get offended too easily! PGP: 7C848198AE93D3BB

Offline

#3 2021-02-02 11:42:39

a821
Member
Registered: 2012-10-31
Posts: 233

Re: [SOLVED] Pacman mirrorlist optimalization horror

Check the pacman manpage for what the double "u" in "-Syuu" does. It does not do what you think it does. Also read about what the double "y" does (spoiler: it is not necessary, except perhaps in extremely rare cases).

Offline

#4 2021-02-02 12:16:03

Ferdinand
Member
From: Norway
Registered: 2020-01-02
Posts: 38

Re: [SOLVED] Pacman mirrorlist optimalization horror

Uhm.. I hear you - but...

https://wiki.archlinux.org/index.php/Mirror wrote:

After creating/editing /etc/pacman.d/mirrorlist, issue the following command:
# pacman -Syyu
...
Warning: In most cases if you force refresh the pacman database, you will want to force downgrade any potentially too-new packages to correspond to the versions offered by the new mirror. This prevents issues where packages are inconsistently upgraded, leading to a partial update.
# pacman -Syyuu

That's why I did the pacman -Syyuu

And really, disregarding the mirror load and what I think or do not think about double "u"s, the question remains:
Shouldn't the mirrors in the mirrorlist have been updated? And if so, then why the downgrade warnings?

Offline

#5 2021-02-02 12:52:48

graysky
Wiki Maintainer
From: :wq
Registered: 2008-12-01
Posts: 10,206
Website

Re: [SOLVED] Pacman mirrorlist optimalization horror

mpan wrote:

This is your best bet.  Perhaps an alias in your shell rc, adjust -c to match your locale:

upp() {
  for i in 1 3 6; do
    if reflector -c US -a $i -p https -l 5 --sort score --save /etc/pacman.d/mirrorlist.reflector 2>/dev/null; then
      cat /etc/pacman.d/mirrorlist.reflector
      pacman -Syu
      return 0
    fi
  done
  echo "--> cannot find a single mirror with sync time in the last 6 hours"
  return 1
}

CPU-optimized Linux-ck packages @ Repo-ck  • AUR packagesZsh and other configs

Offline

#6 2021-02-02 13:05:47

mpan
Member
Registered: 2012-08-01
Posts: 641
Website

Re: [SOLVED] Pacman mirrorlist optimalization horror

Ferdinand wrote:

That's why I did the pacman -Syyuu

Note that the quoted fragment contains a conditonal: “if you force refresh the pacman database”. IF(!) -yy is passed, -uu is suggested to not risk partial upgrades. And the rational for using -yy itself is given just a bit earlier:

Issuing pacman -Syyu is an unnecessary waste of bandwidth in most cases, but can sometimes fix issues when switching from a broken mirror to a working mirror

From a broken mirror, not merely outdated one.

Ferdinand wrote:

Shouldn't the mirrors in the mirrorlist have been updated?

That page gives a view of the official mirror list, applying basic filters on their static properties. No dynamic checks are performed.

Ferdinand wrote:

And if so, then why the downgrade warnings?

Because you are downgrading packages. pacman warns about that, as that’s usually unwanted and unexpected.


Sometimes I seem a bit harsh — don’t get offended too easily! PGP: 7C848198AE93D3BB

Offline

#7 2021-02-02 14:38:14

Ferdinand
Member
From: Norway
Registered: 2020-01-02
Posts: 38

Re: [SOLVED] Pacman mirrorlist optimalization horror

Thanks your replies - @mpan your explanation makes sense to me; I couldn't understand why a "uu" should downgrade from up-to-date mirrors, but of course, if the mirrors aren't updated that would result in downgrades.

I need to rethink my strategy it seems smile

Thanks for the community/reflector tip also - I'll check that out!

Offline

#8 2021-02-02 15:24:13

mpan
Member
Registered: 2012-08-01
Posts: 641
Website

Re: [SOLVED] Pacman mirrorlist optimalization horror

Elaborating a bit more on “why”, though this is just my private view with no authoritative sources, let’s make a thought experiment. Assume that the mirrors website would take some dynamic properties (like being up-to-date) into account. What that entails? The data itself is already being collected for the mirror status. But other points include:

  • Writing, testing and deploying code (someone has to do that).

  • Maintaining that code (someone has to do that).

  • Providing resources (someone has to pay for that). Filtering by static properties is trivial and content can be even semi-static. Not so much for ordering by freshness.

All this to supply a list, which has to be ranked by speed, tested for accessibility and maintained  on the user’s computer. That must be done by client-side tools, like reflector. And reflector already tests freshness.

At this point the explanation seems obvious.

Last edited by mpan (2021-02-02 15:24:51)


Sometimes I seem a bit harsh — don’t get offended too easily! PGP: 7C848198AE93D3BB

Offline

Board footer

Powered by FluxBB