07/01/11 17:58, intrigeri:
> Hi,
>
> anonym wrote (06 Jan 2011 15:36:49 GMT) :
>
>> If we're already approaching the 700 MB limit, perhaps we should
>> look into a lighter DE than Gnome?
>
> I'd rather not to, for several reasons:
>
> 1. Probably thanks to Ubuntu's popularity, lots of users are somehow
> used to GNOME and would need to re-learn non neglictible amounts of
> practical knowledge.
>
> 2. My intuition tells me GNOME offers us a great bunch of useful
> functionality; I fear we would slowly realize this (and need to fix it
> bits after bits) if we switch to something lighter, everytime users
> complain for disappeared functionality. On the other hand I must admit
> I have not tried e.g. XFCE recently, and it might now have most of
> GNOME features we care about. I would be happy to stand corrected on
> this one.
>
> 3. This seems like a very radical change, with important consequences
> both on usability and developement resources. I am not sure it would
> be worth it since:
> - we are currently only slightly above 700MB => we probably can
> manage to workaround this issue for the lifetime of Debian Squeeze
> without coping with such a big change
> - when Debian Squeeze+1 = Wheezy is published (statistically: ~1st
> quarter 2013), bundled software size is likely to have increased
> again, and even using a lighter DE will probably not bring images
> size back under 700MB
> - when Wheezy is published, we might be in a position to reasonnably
> target DVD and USB rather than CD.
Fair enough.
>> 1. Let's clear out /var/lib/apt/lists (except the sub-dir called
>> "partial", which can be left empty). That's 60 MB in T(A)ILS 0.6.1.
>
> This seemed like the lower hanging fruit => done in devel branch.
>
>> That makes it annoying to install new software though since one has
>> to "apt-get update" before.
>
> Yep. It will mostly annoy... ourselves I guess. I very frequently need
> to do so while developing T(A)ILS.
Therefore it might be a good compromise to only do this for final
releases and perhaps the later rc:s. I suppose all (?) of us use virtual
machines for testing, so larger images are not problematic at these stages.
>> If we choose to do this, perhaps this directory is another candidate
>> for being persistent once that has been implemented?
>
> Sure.
>
>> 2. One thing I cleared in Incognito for additional space was
>> /usr/share/doc, which in T(A)ILS 0.6.1 amounts to another 66 MB. One
>> possible legal problem with this is that licenses usually reside there,
>> and I guess most licenses require them to be shipped with any binary
>> distribution. Parhaps we could have a script which re-names them
>> appropriately and puts them in a licences subdir? E.g.
>> /usr/share/doc/tor/copyright --> /usr/share/doc/licences/tor-copyright, etc.
>
> I'd like to go on shipping documentation (other than manpages) for the
> bundled software, for usability reasons. Why not, if we have no better
> choice... but it seems Alan suggested less drastic ways to lower
> images size. We'll see.
I agree that the documents in /usr/share/doc can be useful, but I think
we can assume that _very_ few of our users will ever look in there.
Also, this documentation can in most cases be found easily on the
internets any way.
>> > I suppose that translates to about half when compression is taken
>> > into account.
>
> The average compression ratio (rootfs -> squashfs) is rather 1:3.
For the record, I ran a simple test (in 0.6.1) using gzip to see how my
two suggestions turned out:
* /var/lib/lists reduced massively, from 60 MB to just 16 MB (lots of
redundancy in there apparently). This makes me question a bit if it's
worth the additional hassle of having to apt-get update.
* /usr/share/doc reduced from 66 MB to just 51 MB. After all, most large
files in there are already compressed. For instance, there are 36 MB
worth of _gzipped_ changelogs, which I must admit I find of doubtful
practical usage for the end user.
Well, let's think of fiddling with /usr/share/doc as a last resort.
Cheers!
