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 <ARCH> 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 4947 4
linux-image-KABI-powerpc-smp 2.6.26-21/23509576 2.6.32-15/28634896 5125320 5005 4
linux-image-KABI-powerpc64 2.6.26-21/23369286 2.6.32-15/29785936 6416650 6266 6
linux-image-KABI-486 2.6.26-21/20181780 2.6.32-15/26949060 6767280 6608 6
linux-image-KABI-686 2.6.26-21/20216832 2.6.32-15/27077640 6860808 6700 6
linux-image-KABI-amd64 2.6.26-21/20874922 2.6.32-15/28155342 7280420 7109 6
linux-image-KABI-amd64 2.6.26-21/20893606 2.6.32-15/28257430 7363824 7191 7
linux-image-KABI-686-bigmem - 2.6.32-15/27213342 27213342 26575 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 along the dependencies
too?
Ian.
--
Ian Campbell
Current Noise: Anthrax - Who Cares Wins
So live that you wouldn't be ashamed to sell the family parrot to the
town gossip.
Reply to: