gEDA-dev: Random comments consolidated (chroot'd geda bloat)

Igor2 igor2 at inno.bme.hu
Tue Aug 1 03:56:11 EDT 2006


On Mon, 31 Jul 2006, Ales Hvezda wrote:

>* Igor2, your chroot distribution is pretty cool.  A little big, but 
>  cool never the less.  I bet it could be trimmed down significantly.

Ales,

thanx :) Of course, it's much bigger than needed. The main reason for this
is using Debian. If I would compile everything by hand and copy only the
really needed files in the chroot, it could be halved. However, this would
be way too much work, I think: the users who would use such a chroot'd
distribution expect to get _everything_ in it so they shouldn't worry
about the size. Btw, I've started to remove layers from 0.0.3 to see what
takes up the space and I think it's interesting anough to share:

1. Starting size is 189 megs. This contains a full functional Debian
without a kernel, all the x libs, binaries and other files needed to run
geda and geda itself.

2. Removing geda (geda-doc geda-gnetlist geda-gschem geda-symbols) frees
up 19 megs. Ok, this could be reduced by hand-compiling.

3. Removing PCB (with tk and tcl, which this version somehow needs) frees
up 9 megs. Also could be reduced by hand-compiling.

4. Removing X libs, libs for png and jpeg, fonts, font libs and glib frees
up 39 megs. Could be reduced by hand compiling, but this assumes deeper
knowledge about those libs. 

5. Removing python and m4 frees up 21 megs. Here I'm less sure hand
compiling would save much.

At the end, only about 100 megs is left, which is the overhead of Debian
itself. By removing even more pacakges, I could go down 72 megs. This
means the overhead is between 40% and 50% in this test version. Of course
this rate will get better when all tools are installed. I think the final
overhead would be around 30%. Some further optimization could be
considered, for example using busybox instead of binutils and co.

It's a valid question whether such a chroot'd distribution should have
that overhead or not. For the test I choosed it to be able to produce a
test case ASAP. Still I believe it would be a good choice for real
distributions as well:

- The chroot'd system contains all basic binaries and libs so if the user
wants to add 3rd party scripts/programs to enhance the functionality of
his gEDA suite, he won't face unexpected dependency problems. If
he wants to run a perl, python or awk script, he can. 

- Maintenance of the system becomes simpler. If new version of gEDA starts
depending on libfoo, we don't need to compile it by hand and walk trough
the dependencies to install everything needed in the jail, rather we just
say apt-get install libfoo. It's a bit selfish reason as the user may not
care about how comfortable or easy to keep a distribution up to date, he
cares about the result - but the same argument can be mirrored back: if he
cares, he could install software himself/herself to avoid waste.

- Testing. If we use a distribution's package manager to install all
programs and libs, we also use the testing the maintainers/testers/users 
of that distribution invested. 


Well, all these are details. I think the most important question now is
whether this idea really works on actual random distributions for real
users. 

cheers,

Igor2



More information about the geda-dev mailing list