Re: CD mirrors
- To: email@example.com
- Subject: Re: CD mirrors
- From: Mattias Wadenstein <firstname.lastname@example.org>
- Date: Fri, 1 Oct 2004 17:14:23 +0200 (MEST)
- Message-id: <Pine.GSO.email@example.com>
- In-reply-to: <20040930104820.GA5401@fluff>
- References: <Pine.GSO.firstname.lastname@example.org> <20040922085623.GA18670@nenya.lan> <Pine.GSO.email@example.com> <20040922101124.GB18670@nenya.lan> <Pine.GSO.firstname.lastname@example.org> <20040922113613.GA10009@nenya.lan> <Pine.GSO.email@example.com> <20040930104820.GA5401@fluff>
On Thu, 30 Sep 2004, Richard Atterer wrote:
please have a look at the new <http://www.debian.org/CD/mirroring/>, I hope
the information is now closer to the truth than before. :-7
Mattias, is the page correct from your POV?
Yeah, it looks alright.
Some further notes:
* The rsync URL for the beta/unstable/testing images does not have a "pub/"
in it, unlike the HTTP/FTP URLs. Is it worth it to make this uniform or
should we just leave it like that?
I've added pub/ if you want that, both are available.
One note though, the the full isos aren't in cdimage-testing, but in
pub/weekly/ right now. This because cdimage-testing is a plain mirror from
gluck with nothing added.
Manty, etc: Should we look at getting a consensus on what isos we would
like published and then put them into the cdimage-testing directory? With
the goal of having cdimage-testing (or some other directory) turn into
what is supposed to be a drop-in replacement for debian-cd/ at release
* I'm boldly declaring on the page that DVD images have names ending in
-dvd.iso and dual-layer images have names ending in -dldvd.iso!
* For consistency, should CD images' names end in -cd.iso? It might make it
easier for mirror admins to in/exclude CD images from mirroring.
I think this would be a good idea.
* I don't remember clearly what the plans WRT full DVD images were: Will
there be a full set of images for all arches? Probably not... full set for
i386? One DVD image for i386? What about dual-layer? %-| (IOW: Mattias, how
much disk space will be available by release time?;)
<http://www.debian.org/CD/mirroring/#names> is probably wrong ATM.
The space available would be 100-120 gigs, this both on cdimage.d.o and on
the primary push-triggered mirrors (at least, this is what I asked of
them when they signed up). I think we agreed that dual-layer isos would be
overkill, since those are primarily of interest for vendors, not
individual users. But that a full i386 dvd set would be very good to
carry. As would iso sets.
* Could /export/ftp/pub/cdimage-testing on farbror be made writable by
deb-cd? I'd like to install a cron job which runs "du" over the CD image
directories, so that prospective mirror admins can always get up-to-date
info on the actual size requirements. I was thinking of publishing the "du"
output as /export/ftp/pub/cdimage-testing/cdmirror-sizes.txt...
I'll take a look at it.
On Wed, Sep 22, 2004 at 01:51:57PM +0200, Mattias Wadenstein wrote:
On Wed, 22 Sep 2004, Richard Atterer wrote:
Can you provide a list of directory paths for the various image
variants? IOW, if full images of single/dual-layer DVDs, netinst,
business-card etc images are made available, where on the server will
they appear, and where the corresponding .jigdo/.template files, if any?
Not yet, and I need some input on this. How should this be organized so
the users can find the correct jigdo and iso? My suggestion so far has
been to put them all into the same arch directory and make the name
reflect what kind of iso/jigdo it is. Any other suggestions/comments?
IMHO, this is fine! The rsync --include/--exclude options on the page now
also describe how to in/exclude by filename.
That looks good to me.
The directory listing will look confusing especially to new Debian users
because e.g. DVD and CD .jigdo files will be all mixed up. However, I've
thought for a while that just linking to Apache dir listings is not a good
idea considering the growing number of download possibilities. *sigh*, yet
another little project to come up with an intuitive set of pages... :-)
Well, right now we at least have a split on download method
(jigdo/iso/torrent) and architecture. Imagine if we put everything in a
single directory.. ;)