Hi! As everybody that has created debian cds using debian-cd knows, it is difficult to estimate the image sizes, till now I had been using my own estimations at gluck and it is now when I switched to debian-cd current estimations that DVD and CD sizes have gone wrong.
So, I'd like to fix what we currently have in debian-cd, Raphael sugested (if I recall well) that we should change the disks-$ARCH directory size by the size of the installer-$ARCH directory (Raphael, correct me if this was not what you told me), the problem here is that not all the images in the installer dir are used, for ecample: du -s debian/dists/sarge/main/installer-i386/current/images/ 60064 debian/dists/sarge/main/installer-i386/current/images ls debian/dists/sarge/main/installer-i386/current/images/ MANIFEST MD5SUMS cdrom floppy hd-media netboot The thing is that only 20 megs aprox of this dir are used, which corresponds to the cdrom and floppy dirs, but this can change with the arches. The only way I see to estimate images sizes in the cds would be to do the download/cp of the images from the web/mirror into the tmp directory before we calculate the sizes, thus in the build.sh script. I can see, without thinking too much on the problem and not knowing the code well, at least a way to do this: calling the boot scripts with a "predownload" parameter that only does the downloading or cp of all the stuff to a dir into the tmp space, and then when the boot script is called in the usual way by the Makefile, they check that this dir is already created and they don't download the stuff again. This would mean that we need to modify all boot scripts. What we'd get of this, would be the real size of all the extra stuff put on the cds for all the arches in real time, wich is one of the parameters we are looking for. If we take a real example where the space reserved for boot files was 0... CD 1 filled with 652854624 bytes ... (limit was 660602880) this means that it is calculating around 622 megs of packages, and it ended up with an image of 650MB If we analyse the space in the tmp dir for CD1... /CD1$ du -s --apparent-size * 11 README.html 76 README.mirrors.html 38 README.mirrors.txt 6 README.txt 1 debian 1430 dists 771 doc 20457 install 115 md5sum.txt 19 pics 640410 pool 986 tools we can see that pool has 626 megs, which is a little bit more than calculated (anybody knows where this 4 megs came from?), and then we see that most of the other space is from the install directory (the space I was trying to estimate coming from the boot images and all that) and then a bit from the doc, tools and dists (packages files), if we stimate by hand the size of these last ones and we calculate the size of the images we can have a good stimation on the size of the files we are putting in, don't you think? For example, here the estimation would say that for doc, packages and other stuff we need 4 megs, then we calculate the size of install, which is 20, and we add that to the 622 that we had already, and we get 646, which is a little bit under the ISO size, but that is a good estimation as we didn't take into account the extras that the filesystem imposes. That is another of the problems we have, estimating the extra space added by the filesystem, for what I know, that can change quite a lot the size of the images on some arches, I know we already have some ways to try to estimate this, but I haven't yet examined this, anybody that knows other arches or the scripts we use for this wants to say something on this? is this really problematic? or to we already have a solution for this? We'll I now have a quite fast raid 0 here at home, so I'll be making some tests, here, but what I don't have is a good bandwith to be able to make tests with all arches and right now I only have a mirror for i386 :-( I accept all kind of help, comments, hints, ... with all this, I don't know the code we use for all this size estimations, so anybody wanting to help is at least as qualified as I aam ;-) Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
