Syncing some architectures first and others later (per architecture Release file?)
Hi,
It was recently brought up to the attention of the mirrors team that at
least one mirror is syncing some architectures first (i386 and amd64) and
then the rest at a later time. By doing this the mirror's indexes are
inconsistent for up to ~100 minutes for the all the architectures other than
i386 and amd64 *during the freeze*.
This is done by the mirror admins as a compromise between offering a more or
less up to date mirror for i386 and amd64 while not leaving users of the
other architectures in the cold.
Now, I'm bring this issue up here so that it can be taken into consideration
for future archive changes. I'm not sure if we actually want to support this
kind of setup, but the only technical barrier I see is the use of a single
In/Release file no matter how many architectures are included. So it doesn't
seem like we should have such barrier either.
Any change in any direction is likely to require an update to all the
involved parties: archive software, mirror sync scripts, client code.
(Insert http.d.n and cdn.d.n somewhere.)
From the http.d.n POV it would be helpful to have the architecture
information sent when requesting the Release file. It could just say "there's
no mirror in your country with mipsel, so fetch Release and all the other
indexes from this other mirror" instead of "here, fetch Release from your
local mirror" [and when the request for binary-mipsel/... arrives] "oh noes,
now what other mirror is as up to date or as out of date as the mirror you
fetched the Release file from and has the file for the architecture you want?"
The latter doesn't happen nowadays since the redirector creates subsets of
up to date mirrors and discards any mirror that is out of date (even if only
be a few hours). This approach has its own issues besides the fact that it
prevents it from using some mirrors, but I want to switch away from it to
further increase the number of mirrors in actual use. An example of an issue
with the current approach: https://github.com/rgeissert/http-
redirector/issues/33
Cheers,
--
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Reply to: