Re: ftpsync test please
Raphael Geissert (geissert@debian.org) wrote on 7 May 2012 22:55:
>Hi,
>
>On Mon, May 07, 2012 at 05:29:13PM -0300, Carlos Carvalho wrote:
>> Joerg Jaspert (joerg@debian.org) wrote on 6 May 2012 17:18:
>> >On 12837 March 1977, Carlos Carvalho wrote:
>> >> Joerg Jaspert (joerg@ganneff.de) wrote on 1 May 2012 01:03:
>> OK, seems to be easy to do. Please specify the format of the list in
>> the trace file.
>
>Basically, the value of Architecture can be defined as:
>
>VALUE := TOKEN{ARCH_LIST} [ARCH_LIST] | ARCH_LIST
>ARCH_LIST := ARCH [ARCH_LIST]
>TOKEN := "FULL" | "COMMON" | "GUESSED"
>ARCH := "amd64" | "i386" | ...
...
>The order not relevant. The definition of the tokens is hard-coded,
>hence the need of explicitly naming their value.
So you need to state the full list of architectures as they'll be
recognized by you.
This arrangement forces mirrors to have both a list of all archs and
another for the excluded ones. Worse, it requires admins to update the
config each time a new arch is added or removed. This is bad, you'll
end up with incomplete lists of archs in the trace file.
A possibility to avoid mirrors having to enumerate the archs they
distribute is to state a rule of forming it by the files in dists.
Better still, you can determine it by scanning dists/ in the mirror.
>> >> >And they show which Upstream mirror is used.
>> >> This is not necessary. It can be deduced by the trace files in the
>> >> directory. Further, it may not be easy to do because what's in the
>> >> script variable is not always the upstream host name.
>> >
>> >It can be decuded. Most of the times. Not always.
>>
>> If all mirrors do the trace it can be deduced. If some don't this is
>> the real problem and we shouldn't bother those who do because of
>> these...
>
>There are mirrors that only serve over http. You would need to parse
>the directory listing to obtain the file names and then send a request
>to each file to guarantee a) that you got the name right, and b) to
>guarantee the modification date, as not all httpds include the date in
>the dir listing.
Yes, so you know what you have to do. And it'll avoid the need to
include the list of distributed architectures as well.
>Btw, this is not just about http.d.n. sending multiple requests
>(scanning) or parsing html to find out what a mirror is actually
>including or where it is mirroring from, is silly.
Only if the alternative is not putting more work on those that already
do better.
>It might seem or actually be easy to implement, but it is not
>deterministic.
Why what you've described is not deterministic?
Reply to: