On Mon, Jun 28, 2010 at 07:38:18PM +0100, Ian Campbell wrote:
>On Tue, 2010-06-15 at 14:30 +0100, Steve McIntyre wrote:
>> The following packages are falling off onto a second disk now:
>>
>> i386:main:linux-image-2.6.32-5-686-bigmem:27213342
>> i386:main:linux-image-2.6-686-bigmem:3036
>> i386:main:linux-headers-2.6.32-5-686-bigmem:516338
>> i386:main:linux-headers-2.6-686-bigmem:2930
>
>Is this list part of the output somewhere when I do a local build either
>with easy-build.sh or by replicating the invocation from debian-cd-setup
>SVN?
It's an excerpt from make_disc_tree.log, produced when
make_disc_trees.pl is laying out packages into the temporary trees. It
logs into the temporary directory where debian-cd is working.
>On Fri, 2010-06-25 at 21:51 +0100, Ian Campbell wrote:
>> One thing to note is that the amd64 xen images should by symlinks to
>> the regular vmlinuz+gtk/initrd.gz images (since no special kernel is
>> needed on 64 bit, the intention was to symlink just for consistency in
>> the path to the kernel for convenience) so there is an immediate 18.3M
>> saving to be made which I will look into.
>
>This was inconvenienced a little because the images can be fetched from
>the web and hence the symlinks aren't directly detectable, but here is
>what I arrived at. However even with this a bunch of stuff gets punted
>to CD2, in my case it is:
>/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686_2.6.32-15_i386.deb
>/pool/main/l/linux-2.6/linux-headers-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
>/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-15_i386.deb
>/pool/main/l/linux-2.6/linux-image-2.6.32-5-686-bigmem_2.6.32-15_i386.deb
>/pool/main/l/linux-latest-2.6/linux-headers-2.6-686_2.6.32+27_i386.deb
>/pool/main/l/linux-latest-2.6/linux-headers-2.6-686-bigmem_2.6.32+27_i386.deb
>/pool/main/l/linux-latest-2.6/linux-image-2.6-686_2.6.32+27_i386.deb
>/pool/main/l/linux-latest-2.6/linux-image-2.6-686-bigmem_2.6.32+27_i386.deb
>which is less than ideal.
>
>This is with the Xen initrd pared down to the non-GTK version too -- I'm
>not sure what else can be done to fit stuff on CD1 now...
Hmmm, OK.
>Subject: boot-x86: detect duplicates in the extra images used for installation
>
>Several files included under install.{386,amd} are actually identical to
>others. Rather than duplicating them attempt to detect this and symlink
>them.
I don't think sym-links are going to work - the filesystem code in
isolinux is very simple (e.g. it only supports basic 8.3 filenames!)
and I doubt it'll work. Hard links *might*, however.
>Since images can be downloaded from the web at build time it is not
>always possible to detect identical files by looking for the symlinks
>created by the debian-installer build. Instead we pass a list of
>potential "doppelgangers" to extra_image each of which is checked for
>similarity to the new image.
>
>I added gtk/vmlinuz (which is always the same as plain vmlinuz) which
>although not necessary makes it more explicit which kernel goes with the
>initrd at very little cost.
>
>(it's not clear if hardlinks or symlinks should be preferred. I chose
>symlinks largely arbitrarily but I don't know if this has implications
>for compatibility with other, non-symlink supporting, OSes which may
>wish to read the CD)
:-)
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100628214357.gf4...@einval.com
