Közeleg a kövér cowboy...

Címkék

Richard Atterer, a jigdo írója a debian-cd levelező listára küldött levelében a közelgő Woodyról és az ezzel kapcsolatos problémákról beszél.A levél szerint Richard a következő hetekre teszi az új Debian kiadás megjelenését, amellyel kapcsolatban a legkritikusabb a tükrözés lesz, a nagy számú CD-k miatt.

A Debian előző kiadása, a potato CD-i 13 GB helyet igényeltek a 22 CD számára. A Woody kiadás ezzel szemben 53 GB-nyi helyet fog foglalni, 88 db CD-vel. A drasztikus növekedés oka az architektúránkénti 3 CD helyetti 8, illetve a potato 6 architektúrája helyett támogatott 10. A CD-k óriási mérete miatt valószínűsíthető, hogy a tükrök ezeknek csak egy kis részét fogják hordozni, így ezt elkerülendő hivatalosan a nem Intel architektúrákhoz csak az első három CD-t tennék letölthetővé. Ilymódon egy "teljes" Debian CD tükör 34 db. CD-ből fog állni, 21 GB-nyi helyet elfoglalva.

Azoknak, akik mind a 88 CD-t tükrözni szeretnék, a jigdo-t kell használniuk.



Az eredeti levél:

Date: Thu, 30 May 2002 14:16:14 +0200

From: Richard Atterer

To: debian-cd@lists.debian.org

Subject: Re: CD release announcement




Hello,




this is my first attempt at a note to mail to all CD mirror admins.

Doubtlessly it is inaccurate in some places - please correct any

mistakes. Is there any important issue which I missed, and which
the
mirror maintainers should know about?



Where will the official 3.0r0 jigdo files be placed? I think it would

be wise *not* to use cdimage/jigdo-area for that, because

- ATM jigdo-mirror will attempt to re-generate any non-existent

images every time it is run. IOW, if mirror admins mirror

jigdo-area/ and then let jigdo-mirror loose on it, the script will

work several minutes on each pre-release image, only to realize

that it is unable to re-create it.

- When 3.0r0 is out and Phil starts making 3.0r1 pre-releases, all

mirrors will pick those up, attempt to create them, maybe
overflow
their disks etc... not desirable!




Another related question: At the moment, jigdo-mirror does not
allow
you to filter which images it should create and which not. People

using it will only be able to mirror all 88 images, there's no way to

prevent it from creating e.g. binary-3 to binary-7, or the non-us
CDs.
Should I modify it to allow such filtering?




----------------------------------------------------------------------

Release of CD images for the Debian Linux 3.0r0 release ("woody")

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




This mail was sent to you because your address is stored in our

database of Debian CD mirror servers and your server is listed
on
http://www.debian.org/CD/http-ftp/. Note that if you reply to
this
mail, your answer will by default be sent to

, a public mailing list.

[Reply-To will be set up accordingly.]




Within the next weeks, Debian 3.0 "woody" will be released and
new CD
images will be made available. Here is some information about the

release of the new CD images.




Size requirements

~~~~~~~~~~~~~~~~~

[Please correct numbers - they may be completely wrong!]



The images of the current stable distribution ("potato") need 13
GB of
disc space for 22 CD images. In contrast to this, the full set of

"woody" CDs needs about 53 GB for 88 CD images! [The 88 is
8*10 + 8
source.]

This increase is due to the larger number of CDs (8, used to be
3) per
architecture, and the larger number of architectures (10, used to
be
6).



Because we expect that most mirror admins do not want to
dedicate so
much space to CD images, by default not all CD images will be
made
available, only a subset which will take about 21 GB for 34 CD
images.
(We omit CDs 3-8 for the 9 non-Intel architectures.)



Required setup changes on your mirror

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




You do not need to change anything about your current mirror
setup if
you want to distribute the default set of 34 CD images - the old

"debcdmirror" scheme as well as rsync or FTP/HTTP mirroring will

continue to work.

[Is this correct? Will PIK-style .list files be generated? Will the

rsync/http/ftp paths stay the same?]




However, consider changing the mirror setup as described below
if one
of the following applies:




- You want to update your mirror quickly after the release. In our

experience, the master site will be under extremely heavy load

immediately after the release, possibly even to the point of not

being reachable.

- You already have a local "regular" Debian FTP mirror. In this
case,
the mirroring can be made much more efficient now.

- You want to offer the full set of 88 CD images.




New way of mirroring: jigdo-mirror

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~




jigdo is a new way of generating Debian CD images. A local
(=same
machine) Debian FTP mirror is required for this. Additionally, if
the
mirror does not run Linux on Intel, you'll have to compile jigdo

yourself - you need a recent C++ compiler (e.g. GCC 2.95) for
this.



The jigdo-mirror script to automate mirroring of Debian's CD
images is
new and needs more testing - if you can, please try it out now on
the
3.0 pre-release images and report any success/failure to us!




jigdo-mirror takes packages from the mirror as well as special
files
with ".jigdo" and ".template" extensions, and assembles the CD
images
from all this information. This makes it similar to how
debcdmirror
works, with the important difference that jigdo does not rely on
rsync
to produce the final image.




A jigdo-based mirror requires

- setting up a normal Debian FTP mirror http://www.debian.org/mirror/

- setting up HTTP mirroring of the .jigdo/.template files

- setting up a cronjob which runs jigdo-mirror at regular
intervals
- configuring jigdo-mirror. This should be easy, it hardly needs
more
information than the paths to the .jigdo/.template files and
your
Debian FTP mirror.




Links

~~~~~

Debian on CD:

http://www.debian.org/CD/

Retrieving Debian CDs with jigdo:

http://www.debian.org/CD/jigdo-cd/




rsync path for stable CD images:

rsync://cdimage.debian.org/debian-cd/

(Try not to mirror directly from the master site if possible.)

HTTP access is disabled for the images themselves, but the
MD5SUM
files and .list files can be fetched here:

http://cdimage.debian.org/cd-images/

jigdo homepage:

http://atterer.net/jigdo/

How to set up jigdo-mirror:

http://atterer.net/jigdo/jigdo-mirror.html

Precompiled jigdo binary for i386 Linux, including
documentation:
http://atterer.net/jigdo/jigdo-bin-0.6.6.tar.bz2

jigdo source code:

http://atterer.net/jigdo/jigdo-0.6.6.tar.bz2




.jigdo/.template files for pre-release tests of Debian 3.0:

http://cdimage.debian.org/jigdo-area/

The .jigdo/.template files for 3.0 will be made available here:

[WILL THEY?]

http://cdimage.debian.org/jigdo-area/3.0rev0/




----------------------------------------------------------------------

Hozzászólások

Szerintem, eljött az ideje kettéválasztani a debian stable distro-t. Hasonlóan a FreeBSD, NetBSD pároshoz, kell egy változat az összes csomaggal, a fontosabb architektúrákra (i386, PPC, alpha, sparc) és egy kevesebb csomagból álló az összes többi számára. Így valószínúleg nem húzódna annyit egy újabb stabil release megjelenése néhány olyan csomag miatt, amit csak nagyon kevesen használnak. Később a kisebbik distroba is belekerülhet fokozatosan az összes csomag, /ujabb stable releasekkel/ de igy nem hátráltatná a többieket.
Egy 5let, Bra-nak és azoknak akik mirror-ozzák a debian woody-t cd-image-ként és ftp-tree-ként is. Loopback mountolva a cd-image-ket linkekket érdemes létrehozni a 'böngészhető' /apt-get -elhető/ debian mirrort és igy fele annyi helyet foglal. Csak a package.gz ... fileokat kell kicserélni, a többi nem CD függő.
Persze lehet hogy már rég igy csináljátok.

A FreeBSD-nel es a NetBSD-nel nem igy mukodik a dolog. A FreeBSD-nel egeszen pontosan vannak un. "release"-ek, amelyek a legjobban tesztelt valtozatai az OS-nek. Van a "stable", amely CVS-bol szedheto ki es amelybe csak tesztelt valtozasok kerulhetnek bele, azok a valtozasok, amelyek a harmadik ag, a "current"-ben mar megbizhatonak bizonyultak. Ezt a fejlesztesi modszert a Debian mar atvette, hiszen a SID-bol hasonlokeppen kerulnek le a csomagok a Woodyba. Csak itt nem igazan programfejlesztesrol, hanem a csomagok minosegerol, illetve a masok altal fejlesztett programok minosegerol szol a dolog.

Az otlet nem jo, nagyon korulmenyes ezt igy megoldani. Ennel sokkal jobb megoldas a jigdo, viszont soka lesz, mig azt mindenki megtanulja hasznalni.

sztm forrascsomagbol csak egy lesz, pl, meg van egy binary-all is vhol...

sz

Viszont a security csapat a sok architektúrára fogja:)
Meg talán arra, hogy evvel együtt a csomagok száma is min. megduplázódott!

Igen. meg az is igaz hogy a letoltesek 99%-ka az I386 architekturat erinti. Tehat megcsinalhatnak azt is hogy a security csapat ragyur az i386-ra, megcsinaljak az infrastrukturat, es gyorsan kiadjak. Utana raernek a tobbi "kevesbe porgos" platformmal foglalkozni. Es valoszinuleg igy is lesz.