Okay, but it seems that pacman-mirrors uses this state to detect which mirrors must be probed. That means shortly after a push only one mirror is considered and gets the full load instead of always probing all active mirrors. For my case it would be okay to always probe the full list even if I miss some very fresh updates instead of having a slow mirror. Is this the intended behavior or is it just because there is no other way to figure out if a mirror is still valid for the given state like having another flag that tells if the mirror was synchronized in the last 14 days or similar.
Just found out about the --no-status flag. So I guess my thread can be closed by just running
Thanks all for the explanation. I understand the behavior of pacman-mirrors and I’m happy with the -s flag as this solves my problem by selecting the fastest mirror instead of the mirror with one or two more recent packages. I’m also aware that for security updates that would be not the ideal solution as they are delayed.
So I guess the best approach for speed and security would be:
pacman-mirros -s -c de
pacman-mirrors -c de
Ok, so do you think my approach won’t work as there will be always a big update or is the regular case that only some packages change the stable state of the mirrors and it is ok to first get the update from the fastest, not stable, mirror and than sync the missing updates from the stable mirror?
Either the mirror will be up-to-date or not. You won’t get a few updates first from an out-of-date mirror. Even if you did, you would have a partially updated system, which can break your installation.
The amount of issues stemming from partial mirror sync is a continuous problem hitting quite a few people regularly.
Since manjaro releases things in “packages” at least for stable branch, should it not be possible to ensure all files are of correct version before installing a “package” ? Things that fall outside this would only be hotfixes etc. that are pushed outside of a “stable update” package
The way rsync works - it that it copies the sync to a temporary folder - then when all is successfully synced - the content of the temporary folder is copied to their respective locations and the removed files are deleted.
This is usually ensuring consistency within a branch as all files will be avaailable at the same time - including the database which holds the information about the new set of files.
The chance of a partial sync for a client connecting to any given mirror during the mirror’s sync process is highly unlikely.
The partial sync one can run into is usually caused by improper use of the sync command e.g.