@handy @conky57 @jsamyth
This is going to be a long post - ye be warned
My background in this project
I am retired but from my work life have a decent experience in coding and application development and when @huluti asked for help to clean up the code, I volunteered, told him - I know nothing of python, but I am up for a challenge. I have since found python to be an extremely powerful and yet easy to learn language.
The concepts as I have learned them
When I joined this project I had a bit of a difficulty with some of the concepts.
Pacman-Mirrors basically consisted of 3 elements.
Feel free to correct me if I am wrong about some of the historical data
- A number of country mirror files
- A mirror list
- A custom mirror file
- before my time a hybrid between a mirrorlist and a mirrorfile
- began existence in /etc/pacman.d/Custom
- at some time pacman-mirrors began moving the file to /var/lib/pacman-mirrors
About the time I joined a GUI for selecting mirrors had been devised and its contents was written to the custom mirror file.
As I was on Arch Linux I was used to only a mirrorlist and the concept of both a mirror list and a mirror file was confusing at first. I learned that the difference between a mirror file and a mirror list is the branch.
Server = https://mirror.uta.edu.ec/manjaro/unstable/$repo/$arch
Server = https://mirror.uta.edu.ec/manjaro/$branch/$repo/$arch
And it is at this point some of handy's problems began, because he learned - exactly as I did, that the Custom file is no longer a mirror list but a mirror file and when writing the mirror file you have a placeholder $branch instead of an explicitly defined branch.
What has lead pacman-mirrors to json?
In the process of rewriting and cleaning up the internals for duplicate code and other shortcuts I came up with the idea of storing the calculations made by pacman-mirrors about response-time and last-repo-sync in - you get it - json. The idea was rejected by the team but not more than - this is a good idea - we take it server side. And not long after @philm and @huluti began creating what we have know at repo.manjaro.org and the data files used.
Since then I have occupied myself by rewriting pacman-mirrors and it has been totally rewritten. There is not that corner I have not been in optimizing and restructuring and the result is v4 and of course small bugs and annoyances which has been ironed out in a 4.0.1-dev.
Is it a bug?
I have been reading through this thread and it seems a little confusing exists.
When you use the --interactive argument, you are also telling pacman-mirrors you want a custom mirror file now now as custom-mirrors.json. Pacman-Mirrors then modify your pacman-mirrors.conf so every time this custom mirror file is loaded and used.
Since the device of the Custom mirrorfile it has been a manual task to create that file. And it was a manual task to get pacman-mirrors to recognize it. The how-to you have produced does it backwards since you modify the conf file to load the custom-mirrors.json. In that case you won't get all the mirrors from the default mirror file.
You will have to reverse your view of the custom mirror file. Think this way - You don't have a custom mirror file - how do I get one. The GUI and TUI has been created to take the hazzle of creating your custom-mirrors.json. Actually - Hugo has made some sorting functionality (only in GUI) without compromising the rank/random intent.
Pick the mirrors and exit and it saves a custom-mirrors.json and your pacman mirrorlist.
If you want to rank your mirrors you run
If you want to change your selection without doing the now long ranking you can do
pacman-mirrors -i -m random
From v 4.0.1 - you can click on the headers to sort on url, country, last sync - select your mirrors and exit. They will of course be random but
will rank your custom mirror file and write your mirror list with mirrors ranked by response time.
You are right about the status.json - Pacman-Mirrors does have an idea of which mirrors are updated and this knowledge is brought to use with
pacman-mirrors -f 10
This gives you 10 random - up2date - mirrors ranked by response time. The reasoning behind using random mirrors is that mirrors which update more frequently than others should not be overwhelmed just because they are updated more frequently - like eg netzspielplatz.de or stdout.org does.