Re: Multi-arch netinst getting too big
On Wed, 2010-06-16 at 20:06 +0200, Frans Pop wrote: > On Wednesday 16 June 2010, Steve McIntyre wrote: > > >I'm afraid I don't have any good ideas. Is this particular image > > >supposed to contain a complete base system or just enough to fetch the > > >remainder of the base system from the net? > > > > The netinsts are meant to have the base system, yes. I can't see > > anything obvious myself that we can drop. Maybe time to give up on > > powerpc on that image, like we've done on the m-a DVD. Shame, but > > there's only so much stuff we can accommodate here. Anybody else have > > an opinion here? Frans/Joey? > > The i386 netinst has also grown substantially. The base system probably > needs cleaning as part of the final preparations for Squeeze. I suspect > ATM 2 versions of Python get installed for example, Doesn't look like there is any python on the multiarch netinst ISO and I can't see any other instances of the general problem. > and probably some (old) libs have a too high priority. If that is determined to be the case then what is the response? Is it to file bugs against ftp-master or the individual packages? > Someone will have to do a detailed comparison between Lenny and Squeeze > images to see where the changes are and whether some cleanup is possible. > Possibly some udebs and/or packages can be excluded. The Lenny multi arch netinst amd64+i3486+powerpc was 472M which left around 178M spare so I wonder where that space has gone. I wrote some scripts to analyse what has changed from the package lists. They are attached, although I don't pretend anything in there is the best way to achieve the aim. compare-sizes.sh fetches the necessary indexes and compare-sizes.py will tabulate the packages in the Lenny list vs those in the daily image with sizes (in bytes, kilobytes then megabytes). Piping to "sort -k 4 -g" orders by size increase. Overall the i386 packages seem to have increased by 69M, amd64 by 28M and powerpc by 30M for an total increase of 128M (suggesting that ~50M of increase is from non-packaged content) Looking at i386 the clear biggest addition is the 686-bigmem kernels (31M in total include udebs etc) but that was expected, excluding those brings the i386 increase to only 38M which is more in line with the other architectures, but still 10M large for some reason. Each of the existing kernel flavours seems to have gained 4-7M on every arch for a total of 42M extra (not including the 686-bigmem kernel on i386) for i in i386 amd64 powerpc ; do ./compare-sizes.py $i | grep linux-image-KABI; done | sort -k 4 -g linux-image-KABI-powerpc 2.6.26-21/23112884 2.6.32-15/28179348 5066464 49474 linux-image-KABI-powerpc-smp 2.6.26-21/23509576 2.6.32-15/28634896 5125320 50054 linux-image-KABI-powerpc642.6.26-21/23369286 2.6.32-15/29785936 6416650 62666 linux-image-KABI-486 2.6.26-21/20181780 2.6.32-15/26949060 6767280 66086 linux-image-KABI-686 2.6.26-21/20216832 2.6.32-15/27077640 6860808 67006 linux-image-KABI-amd642.6.26-21/20874922 2.6.32-15/28155342 7280420 71096 linux-image-KABI-amd642.6.26-21/20893606 2.6.32-15/28257430 7363824 71917 linux-image-KABI-686-bigmem - 2.6.32-15/27213342 2721334226575 25 Something seems to be pulling in perl now (not just perl-base like in Lenny). Perl is ~4M on each architecture + ~3M of arch:all perl-modules. In addition it appears to pull in libdb4.7 whereas everything else needs libdb4.8 leading to two versions of this library for each arch (not that it is especially large). I can't see anything which depends on perl on the ISO and the perl package is Priority: standard according to the Packages file so I'm not sure how it gets included. There is an additional gtk udeb (libgtk2.0-0-udeb). I'm not sure if this is expected, I'd have thought it might be part of the initrd? That's about it for the >1M gains. Doesn't look to be much to be shaved off to me, except perhaps perl and it's dependencies. I'll take a look at the non-package content of the DVD next since there seems to ~50M accounted there. Is there any indication of by how much we are currently overflowing? Is it simply the total of: > 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 or does pushing a package to the second disk pull
Re: Multi-arch netinst getting too big
On Wed, 2010-06-23 at 15:45 +0200, Goswin von Brederlow wrote: > Just a crcy idea: Could the plain i386 kernel be droped instead? That > would loose support for i486 and i586 cpus on the m-a CD. But is that > needed there? I guess it is a possibility, I suppose new installs on i486 and i586 class machines are likely to be a dying breed and there are other images which contain that kernel for those occasions. (although I guess the same rationale could be applied to having i386 at all when amd64 is on the image too ;-) ) Does anyone else have an opinion? Ian. -- Ian Campbell Current Noise: Reverend Bizarre - The March Of The War Elephants New Year's Eve is the time of year when a man most feels his age, and his wife most often reminds him to act it. -- Webster's Unafraid Dictionary -- 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/1277475563.25867.118.ca...@zakaz.uk.xensource.com
Re: Multi-arch netinst getting too big
On Fri, 2010-06-25 at 15:17 +0100, Ian Campbell wrote: > The Lenny multi arch netinst amd64+i3486+powerpc was 472M which left > around 178M spare so I wonder where that space has gone. > [...] > I'll take a look at the non-package content of the DVD next since > there seems to ~50M accounted there. So the sid daily build of multi arch netinst amd64+i3486+powerpc is 614M (remember that linux-image-686-bigmem has been bumped) Looking at the space used at the top level: * /pool has gone 385M->494M (+109M, seems in line with analysis in previous mail). * /dists has gone 1.4M->1.5M * /docs has gone 1.5M->1.4M * /install has gone 35M->39M (+4M) * /install.386 has gone 18M->38M (+20M) * /install.amd has gone 19M->40M (+21M) * A few K here and there for /README.*, /syslink, /firmware etc So it looks like other than /pool the big change is to /install*. powerpc64 vmlinux,initrd.gz:8.4M+4.3M=12.7M -> 11M+4.1M=15.1M (+2.4M) powerpc64 vmlinuz-chrp.initrd: 6.5M-> 6.9M (+0.4M) powerpc vmlinux,initrd.gz:5.2M+4.3M=9.5M -> 6.7M+4.0M=10.7M (+1.2M) powerpc vmlinuz-chrp.initrd: 6.1M-> 6.3M (+0.2M) 386 vmlinuz,initrd.gz:1.5M+4.3M=5.8M -> 2.1M+3.9M=6M (+0.2M) 386 gtk initrd.gz:12M -> 15M (+3M) 386 xen vmlinuz,initrd.gz:0M -> 2.3M+15M=17.3M (+17.3) amd vmlinuz,initrd.gz:1.7M+4.4M=6.1M -> 2.3M+4.0M=6.3M (+0.2M) amd gtk initrd.gz:13M -> 16M (+3M) amd xen vmlinuz,initrd.gz:0 -> 2.3M+16M=18.3M (+18.3M) So the minor culprits seems to be a smallish increase in the powerpc vmlinux's and (as Frans predicted) an increase in the gtk initrd.gz's However the major culprit certainly seems to be the xen initrd.gz's. 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. The other obvious thing to consider here would be to switch to a non-GTK initrd for i386/xen which I estimate would save ~10M. It's not clear how useful graphical install is under Xen anyway due to its more server-ish focus. Another option might be to combine gtk/initrd.gz and xen/initrd.gz so that the overhead is only the kernel udebs and not duplicating all the other stuff. This seems likely to be enough to squish everything back onto one CD but doesn't seem like it will buy much headroom after that. It's not that clear to me where there are other savings to be made though. Are both powerpc and powerpc64 used these days? (I honestly have no idea) Ian. -- Ian Campbell "You know, of course, that the Tasmanians, who never committed adultery, are now extinct." -- M. Somerset Maugham signature.asc Description: This is a digitally signed message part
