As far as I can tell, with this new logic, updating endeavouros-mirrorlist does nothing in itself, it just triggers eos-rankmirrors to do its stuff. If eos-rankmirrors is not installed, nothing happens when you update endeavouros-mirrorlist (which is very weird!).
I am not a big fan of that, but I may be misunderstanding it. I would prefer it work exactly the same as with Arch, that is, that updating the endeavouros-mirrorlist just creates a .pacnew file. There is a reason why .pacnew files exist, and just bypassing them without a very good reason feels wrong to me.
Apparently, this will happen only once, and it will be changed before the next update. Read this thread and please see what you can make of it:
However, with a working rate-mirrors endeavouros option, we would have an option to completely get rid of both endeavour-mirrorlist and eos-rankmirrors packages.
The thing is that the backup of the file is being done AFTER it has been replaced with the “standard list” that is installed with endeavouros-mirrorlist. So your backup file contains the default list and not the one that you might have customized before.
Not really a big deal when EOS_AUTO_MIRROR_RANKING is set to yes. The backups however are useless.
For the ones deciding to disable the auto-ranking and manually maintain the mirror list → Their list will be overwritten with the default one on each update of endeavouros-mirrorlist, no matter what…
update:
Added --output-prefix to v0.8.0 (already on AUR).
As for adding endeavouros subcommand: why not, but let’s sync first!
As far as I can tell the bash script fetches this file https://raw.githubusercontent.com/endeavouros-team/PKGBUILDS/master/endeavouros-mirrorlist/endeavouros-mirrorlist for mirror list, so let this be the source of urls. But can we rely on the format of country names here?
endeavouros/x86_64/endeavouros.files is quite small for a decent test, but I can’t seem to find another one, which would have a stable name and would be larger, so let this be the file for speed test
1174
TtitYMlHTtsB8TfromKxGyT8m6nOdo1s
Wed Jan 05 10:58:17 UTC 2022
If the number in the 1st row is the mirror update number, then it makes sense to find out the latest version and filter out all mirrors, which are pending updates.
So I believe what makes sense is: to filter by age and then sort by speed.
And of course this will imply fetching state files for initial filtering and then speed testing the remainder.
Let me know your thoughts before I go any further.
This is what seems to be true to me, but only @manuel can confirm it.
Yes, that’s the official mirrorlist, in Arch format ("Server = <url>"). Since countries are commented out, I suppose their format could change, but I think that’s fairly unlikely. New mirrors in other countries may be added, though.
It doesn’t matter greatly: the tests do not have to be super-accurate, since this repo is hardly ever used, and packages are fairly small.
No idea about this state file, it is different than Arch mirrors which have lastsync and lastupdate. But yes, it makes total sense to filter out the outdated servers and then sort the remainder by speed.
I’m almost asleep, but try to clarify some points.
The mirrorlist file at github is not really the best download place, but getting the endeavouros-mirrorlist package from a mirror makes sense. This is because in some in some countries github or gitlab is blocked.
The format of urls should not change without a very good reason.
As @Kresimir said, it is not really a problem. And when ranking, both connection delay and download time are important.
The first line in the state file tells the update level. Bigger number means more recent update. The eos-rankmirror app, by default, prefers the update level over speed while taking both into account.
The idea of doing automatic mirror ranking for the EndeavousOS mirrorlist has these reasons:
user gets (hopefully) the best mirrorlist for user’s location
when mirrors are added or removed, new ranking may be needed after the update of the mirrorlist package
and the autoranking feature should take care of that.
I designed the eos autoranking to take effect immediately when a new endeavouros-mirrorlist package is updated. For me it sounds better than (effectively) hiding the changes of the new mirrorlist into a .pacnew file.
It’s not really a bug. It just happens AFTER the mirrorlist file has been replaced by endeavouros-mirrorlist (so it backs up the “default list” that just came with endeavouros-mirrorlist instead of the one that was present before the upgrade)-> This is what happens now because instead of putting a pacnew, it’ll just overwrites the mirror file (since that backup line in the PKGBUILD is now disabled).
people who do the auto-ranking probably don’t care because the file is immediately rewritten and don’t care about backups anyways. However those that don’t want auto-ranking end up with the “default-list” provided by endeavouros-mirrorlist (which is not ranked at all). Their customized mirrorlist just get’s overwritten with each update of endeavouros-mirrorlist
Well, it works as it should. In combination with overwriting the mirrorlist rather than .pacnew it just causes undesired behaviour let’s say
The mirrorlist should not be replaced automatically (hence my pull request).
The eos-rankmirrors will anyways regenerate the list with the latest mirrors (if enabled, which is YES by default). So there is no point in overwriting it rather than .pacnew…
Added rate-mirrors endeavouros subcommand in v0.9.0 (already on AUR), it supports both:
[default] fetching mirrors from github: rate-mirrors endeavouros --mirror-list-file="https://raw.githubusercontent.com/endeavouros-team/PKGBUILDS/master/endeavouros-mirrorlist/endeavouros-mirrorlist"
reading mirrors from file: rate-mirrors endeavouros --mirror-list-file="./endeavouros-mirrorlist"
Once the mirror list is fetched, it concurrently reads state files from all mirrors, finding out the latest version. It then filters out all mirrors which have non-latest version and gets down to speed testing.
…
