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

Re: ftpsync test please



On Mon, May 07, 2012 at 09:29:55PM -0300, Carlos Carvalho wrote:
> So you need to state the full list of architectures as they'll be
> recognized by you.

The alternative was to read the definition of the tokens from a file
that is distributed by the mirrors themselves. However, such file would
need to be authenticated, and that would require more tools (gpg, for
instance) and an appropriate setup (for the keyring, etc.)

> 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.

Er, my bad. FULL doesn't require the architectures list as it means no
special exclusion is performed. So (and correcting a few issues):

VALUE := "FULL" | TOKEN [" " ARCH_LIST] | ARCH_LIST
ARCH_LIST := ARCH [" " ARCH_LIST]
TOKEN := NAMED_TOKEN ":{" ARCH_LIST "}"
NAMED_TOKEN := "COMMON" | "GUESSED"
ARCH := "amd64" | "i386" | ...

> This is bad, you'll
> end up with incomplete lists of archs in the trace file.

That's why it should be handled as in ftpsync: you list the
architectures you want somewhere and from it you a) generate the
appropriate rsync --include, and b) you generate 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.

If it's done like in the way described above there's no need for that.
Moreover, it might be a bad idea to make that statement. There are
mirrors that have excluded _$arch files yet dist/ still had the
Packages files...

> Yes, so you know what you have to do. And it'll avoid the need to
> include the list of distributed architectures as well.

No, it is error prone. There's also no guarantee on the format of the
directory listing. There can be no links at all, or built with some js,
etc.

The implemented solution works over all the three protocols: http, ftp,
and rsync. There's no need to make any guess or assumption on the
directory structure or anything else. There's also no need to scan.
You download the trace file and you get all the information you need.

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


Reply to: