Currently, the metalink infrastructure does not support a "keyword" for the "alt" directory. As a result, we had trouble with the boltron release and mirrors. We should probably fix this as:
a) I assume it is easy b) it is really hard to see the problem in advance c) we may want to experiment like this more in the future.
I am not sure what you mean by keyword here... can you provide an example?
@adrian any ideas?
Hmm, an example would be nice. I guess @langdon is looking for something like MirrorManager repositories in the alt tree. Which do not exist right now, I think, because the path regex does not work on the alt tree. But that is just guessing.
Apologies on the lag, but:
doesn't have an option to do:
which means you can't use the mirror network reliably for things under the "alt tree". If you use plain https://mirrors.fedoraproject.org you get mirrors that may not actually be replicating the alt tree.
Unfortunately, I am not sure of the "names" of those "keywords" ("fedora", "updates-released") being unfamiliar with the implementation of the mirror infrastructure.
Can you provide some more information. Which paths are you interested in. pub/alt is a dumping ground without much structure and will require code changes. No massive code changes but the code right now can handle the directory structure in pub/fedora, pub/fedora-secondary, pub/archive and pub/epel. For additional repository detection in pub/alt I need to know where the content you are looking for is located.
Looking in my history I see we talked about other ways to get a up to date list of mirrors:
https://mirrors.fedoraproject.org/mirrorlist?path=pub/alt/unofficial/releases/26/Server/x86_64/os/&country=global
Or
$ curl https://download.fedoraproject.org/pub/alt/unofficial/releases/26/Server/x86_64/os/ -I Location: https://ftp-stud.hs-esslingen.de/pub/Mirrors/alt.fedoraproject.org/unofficial/releases/26/Server/x86_64/os/
So there is currently a way to get re-directed to mirrors which should carry the content.
And now I know that you are probably looking at /pub/alt/unofficial/releases/ , right?
I agree with Adrian on this. Alt has been the Fedora Contrib with a lot of "well I want to have this somewhere." and stuff dropped in whatever that person felt at the time was useful. Even not counting the mirrormanager part, mirrors have not been interested in it mainly because their users don't use anything from it. Most of them only mirror /pub/fedora and /pub/epel. Fedora-secondary is a further down and after that you are in the weeds.
Again as Adrian says, I would look at a subtree of alt and either use an existing directory structure. I would however not expect a large number of mirrors.
Well, as I stated in the opening of the ticket, I don't really "need" this anymore as Boltron is "done." However, if we decide to do other things like Boltron (experimental releases) we may run in to this issue. If there is a perfectly good "something else to put in the repo file besides downloads.fp.o" I think this resolves this ticket just fine. I just don't want the next person trying to do an experimental release find out the hard way that mirrors.fp.o will, by default, make no promise that the directory you are targeting has actually been replicated to the mirror it gives you back.
The ticket is really not about "getting more mirrors" just about "as an end user trying to dnf update" I don't get inexplicable failures because the mirror dnf was handed didn't replicate the directory dnf is looking for.
Does that help?
So, given that we have taught mirrormanager about modular releases and it's going to be generating metalinks for them, etc, do we still need to do anything more here?
I agree it would be super awesome if mirrormanager could only redirect people to mirrors that had the exact thing they were trying to get, in practice thats difficult. It means we have to crawl all files on all mirrors, then keep track of which exact ones are up to date not only on a module/repodata, but any arbitrary file. ;( I think it could be done, but will need a lot of development/work.
Metadata Update from @kevin: - Issue close_status updated to: Upstream - Issue status updated to: Closed (was: Open)