[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Syncing some architectures first and others later (per architecture Release file?)


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-

Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Reply to: