Installing recommends and the CD size

[Justin Dugger]

On Wed, Aug 13, 2008 at 8:55 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Michael Vogt [2008-08-08 21:40 +0200]:
>> But it feels to me like we are also doing it now because of size
>> constrains on the CD.
>
> That's actually not quite true. We didn't *drop* those extra
> features/packages, we just didn't *add* them now.
>
> That problem is not related at all to the semantics of Recommends,
> it has been existing forever in Ubuntu.
>
>> I would like to discsuss alternative solutions for this problem:
>>
>> * we could make the CD image scripts not install recommends by
>> default and add a hook similar to the language pack downloads that
>> offers to download and install the missing bits. I think if we are
>> careful with what we allow in here the size that is going to be
>> downloaded is in the range of ~20mb (and its fully optional).
>
> That feels like a bad solution to me. Then the CD wouldn't provide a
> complete desktop any more, but people would feel urged to download
> lots of stuff afterwards and wonder why they just downloaded/installed
> a CD. It would make the CD less useful for offline installations.
>
>> * we could build the CD without recommends and have additional dvd or
>> 1gb usb stick images that contain the missing recommends so that
>> people with more BW can just get those
>
> I'd rather provide a complete 1 GB install image than just an "addon"
> image, since it's much easier to handle. (Provided that we can afford
> the mirror space, etc.)
>
> However, given that we get quite a lot of feedback on CDs, and have
> trouble finding DVD testers, I'd like to keep the images as small as
> possible. I guess it's similar to websites, every additional 100 MB
> costs you so many (100K? million?) downloaders because it's too much
> for their bandwidth/quota.
>
> My feeling is that part of Ubuntu's success is that it is slick and
> small, not overloaded with features, quick to download, and has one
> tool for one purpose (our original design goal). I appreciate that we
> can't always follow the latter, since upstream imposes a lot of weird
> stuff on us (like forcing us to install three HTML rendering engines
> on CDs, xulrunner, gtkhtml, and now webkit, or quite a lot of
> programming languages (Mono, JRE, Python, etc), but our constant
> struggle for space forces us to stay aware of these issues, sort them
> out as soon as possible, and keeps us from building up too much cruft.
> As such, the limited CD space has its advantages, too.

Maybe the CD already uses this, but http://www.squashfs-lzma.org/ has
patches to the kernel to bring in LZMA to the kernel in conjunction
with squashfs.  I'm not sure if squashfs is in the kernel yet, but I'm
pretty sure that the LZMA part isn't.  A related spec can be found
here: https://blueprints.edge.launchpad.net/ubuntu/+spec/dpkg-lzma, in
"Needs Guidance" phase.  In my experience, LZMA works best when it can
find relationships between files, and any compression, including
another LZMA would work to hide them.  For the CD, I wonder if it
would be best to have uncompressed .debs and a compressed FS, since I
imagine the bulk of the CD is .debs.

I realize that solving the problem technically like that might reduce
the incentive to remove cruft, but I imagine there will always be
something else people want on the CD.

Justin Dugger