The most recent update of my system created .pacnew files for both mirrorlist and endeavouros-mirrorlist, and I want to know how to manage them.
I have read the Pacnew section in Arch Wiki and know it recommends manually merging .pacnew files with currently used ones, but in this case that does not seem to be very practical since the two versions look very different, so I want to ask for advice.
Differences between the currently used and .pacnew versions of the mirrorlist file look like this:
Should I find the servers I had uncommented in the standard file, uncomment them in the .pacnew file, delete the mirrorlist file and then rename .pacnew version to mirrorlist? Or is some other way of “merging” them recommended?
For reference, here is how the endeavouros-mirrorlist file looks after I deleted the standard one and renamed the .pacnew version to become the new standard file:
I usually move the existing mirrorlist to a backup, then run rate-mirrors against the new list and start using that.
Actually I have a couple hooks that do it automatically whenever the mirrorlist gets updated, so I never have to think about it or deal with the .pacnew files.
/etc/pacman.d/hooks/10-mirrorlist-backup.hook
[Trigger]
Operation = Upgrade
Type = Package
Target = pacman-mirrorlist
[Action]
Description = Moving mirrorlist to backup...
When = PreTransaction
Exec = /bin/mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
For your main (Arch) mirrorlist, it appears you use reflector.
In that case, I’d completely ignore and delete the .pacnew and instead just manually rerun the command shown in your original mirrorlist (btw, you might want to have reflector service run more often, I believe I had it weekly).
For EOS mirrors, again, depends on what you want to do.
Personally, I either had a 2-3 very specific mirrors I wanted to use “hardcoded” and stable (so ignored and deleted .pacnew), or I completely overwrite the script that generates it (probably overkill if you don’t need customization).
On the other hand, if you don’t care enough and don’t have specific preferences, just adopt the EOS .pacnew as is.
Thank you. If I uncomment select servers in mirrorlist.pacnew, delete mirrorlist and then rename mirrorlist.pacnew to mirrorlist, will that also work? I’m asking because I remember reading older Wiki sections where it recommended moving uncommented servers to the top of the file, etc.
It should work (I’m assuming you are referencing the main/Arch mirrors, since EOS are already uncommented and only commented on the ranking for reference reasons), but I would never advise manual-editing unless it is for the purpose of hard-coding stable selections as described in my previous comment.
I was writting a lot, but instead…
KISS: Just run reflector is my advice.
P.S for future: The hooks suggestions from @BluishHumility are also a great idea, and you can obviously modify them to run reflector instead, if you prefer that.
I was under the impression that you needed to manually uncomment some servers because otherwise it would not check any and not be able to retrieve updates, or would check all of them and thus take a long time, or not prioritise the best ones. I assume that was wrong?
I appreciate all the replies, and will incorporate them into future practices.
You can uncomment them manually, but if you use a tool likerate-mirrors or reflector it takes care of that for you. The tool will figure out which are the best mirrors according to whatever logic is configured in the application, and then uncomment those mirrors (or list them at the top of the file uncommented). Usually you don’t need to go into the file and manually comment or uncomment things unless you are trying to troubleshoot or fix a specific issue.
That’s what I thought too, but given they are not uncommented in mirrorlist.pacnew, and I thought the .pacnew file would have something I would need, I thought I shouldn’t just remove it and rely on reflector-sorted mirrors in mirrorlist.
The mirrorlist package gets updated when there are changes to the mirrorlist. For example, new mirrors have been added, defunct mirrors have been removed, a URL has changed, etc. You don’t necessarily need to have the most recent changes in your file, but you are less likely to run into issues if your mirrorlist is current.
If you are not having issues with the mirrors you are using, you can copy the uncommented list of mirrors and paste it into the top of the pacnew file, then save that as /etc/pacman.d/mirrorlist and just keep using the same mirrors with an updated mirrorlist below (for in case you need to resort at some point).
Keep in mind that the reason a new mirrorlist was sent out from upstream is because it probably contains new mirrors and/or has removed non-functional mirrors.
I am sure you are right, I have not investigated it. I’m not sure why, but for some reason all this time I have had it in my mind that it uses /etc/pacman.d/mirrorlist to sort against.
Edit:
Yes, it looks like it fetches mirrors from the mirror status page like Reflector does.
skip ones, which haven’t completed syncing (--completion=1 option)
skip ones with delays-since-the-last-sync longer than 1 day (--max-delay option)
sort mirrors by “Arch Linux - Mirror Status” score - the lower the better (--sort-mirrors-by=score_asc option)
take the next country to explore (or --entry-country option, US by default – no need to change)
find neighbor countries --country-neighbors-per-country=3, using multiple strategies:
major internet hubs first ( first two jumps only )
closest by distance first ( every jump )
take --country-test-mirrors-per-country=2 mirrors per country, selected at step 6, test speed and find 2 mirrors: 1 fastest and 1 with shortest connection time
take countries of mirrors from step 7 and go to step 5
after --max-jumps=7 jumps are done, take top M mirrors by speed (--top-mirrors-number-to-retest=5), test them with no concurrency, sort by speed and prepend to the resulting list