[Grml] grml-small - raise ISO-size?

[Marc Haber]

On Mon, Sep 17, 2007 at 11:25:50PM +0200, Michael Prokop wrote:
>   grml-small 0.1 started with 49MB total ISO-size,
>   grml-small 0.2 had 56MB,
>   grml-small 0.3 had 58MB and
>   grml-small 0.4 has 60MB now.
> 
> So it's definitely growing (due to the new features of kernel and
> userland in every single release).

Yes, I see that with one crying and one smiling eye.

> The main problem for the grml team so far was, to keep the ISO size
> of grml-small as small as possible but nevertheless provide all the
> software people wanted to see included. Another important drawback
> is the separate kernel version, which had to be maintained
> *additionally* to the main (non-small) grml-kernel.

I understand that, but I could live with "not the latest" and greatesta
kernel in grml-small. Would the work load significantly decrease if
you would only build the -small kernel for every fifth image you
build? Or, can kernel maintenance maybe automated (for example by
obtaining the -small .config file by scripting on the normal .config
file)?

> Using grml-live we are able to build grml-small with one single
> command now. The resulting ISO for grml-small has a size of 133MB
> currently - though the ISO still provides some more software than
> grml-small 0.4 did (like python, aptitude,...) and even a full
> featured /usr/share/doc (24MB) plus the current grml-kernel
> (2.6.22-grml). So the 133MB ISO could be stripped down a little bit
> further (maybe to something like 125MB) without losing toooo much.

I do not care about python, and with most of /var stripped out,
aptitude is not useable anyway. I do not like the idea of having a
larger grml iso at all, mostly because I'll lose the business card CD
(although I have not used grml on a business card CD for at least two
years now), and grml toram takes even more longer now. Additionally,
low memory boxes lose the ability to use grml toram.

> My suggestion therefore is to raise the ISO-size of grml-small to
> something like <=128MB (so it still fits on 128MB USB pens).

Sigh. If you think this is best for the project, go ahead.

> Pros:
> 
> * some more software could be included (and /usr/share/doc could be
>   shipped as well maybe)

That's a non-pro, it's a con. Grml-small's advantage is that it does
not have ballast.

> * use of same kernel version as with full grml -> installing
>   additional Debian kernel packages not being available on the ISO
>   yet (due to lack of space) is no problem furthermore

The current -small kernel is just fine.

> As grml-live will be available to the public soon and everyone might
> build his own grml-version ;-), everyone could build his own
> grml-small version anyway.

I would probably do that, yes.

> So what's *your* opinion about "grml-small grows to ~125MB"?

I don't like the idea too much.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190