[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: C++ support for the D-I



On Mon, Dec 12, 2005 at 09:33:01AM -0500, Lennart Sorensen wrote:
> On Mon, Dec 12, 2005 at 12:04:09PM +0100, Xavier Oswald wrote:
> > Since some days, I'm looking for a better partitioning tool for the
> > D-I.
> > 
> > My idea was using gparted because he is very nice and friendly and it's
> > written in C++/GTK. As I know, C++ libs aren't build in udeb.
> > 
> > So, what do you think about integrating C++ in the D-I or we should look
> > about another partitioning tool written in C ?
> 
> I thought d-i was supposed to be small so we had a chance to have a
> lowmem install option.

I have some serious doubt that you will be able to do graphical d-i in lowmem
situations :) Right now the graphical d-i minimum is something like 64 or 96
MB on x86, so this is hardly a point.

For reference, the powerpc (which has a bit bigger binaries) gparted+lib udeb
has :

$ dpkg -c  gparted-udeb_0.0.8-1_powerpc.udeb

drwxr-xr-x root/root         0 2005-11-23 13:26:09 ./
drwxr-xr-x root/root         0 2005-11-23 13:26:04 ./usr/
drwxr-xr-x root/root         0 2005-11-23 13:26:07 ./usr/lib/
-rw-r--r-- root/root   3048080 2005-11-23 13:26:07 ./usr/lib/libgtkmm-2.4.so.1
-rw-r--r-- root/root    347328 2005-11-23 13:26:07 ./usr/lib/libglibmm-2.4.so.1
-rw-r--r-- root/root    977548 2005-11-23 13:26:07 ./usr/lib/libstdc++.so.6
-rw-r--r-- root/root    151388 2005-11-23 13:26:07 ./usr/lib/libpangomm-1.4.so.1
-rw-r--r-- root/root    279000 2005-11-23 13:26:07 ./usr/lib/libgdkmm-2.4.so.1
-rw-r--r-- root/root    291376 2005-11-23 13:26:07 ./usr/lib/libatkmm-1.6.so.1
-rw-r--r-- root/root     34512 2005-11-23 13:26:07 ./usr/lib/libsigc-2.0.so.0
drwxr-xr-x root/root         0 2005-11-23 13:26:07 ./usr/bin/
-rwxr-xr-x root/root    547052 2005-11-23 13:26:07 ./usr/bin/gparted

For a total sized .udeb of 1.5Mb or so. Notice that this will not be used in
lowmem situation, nor will this .udeb be part of the initial ramdisk image, as
it can be loaded from the network or disk.

The biggest library is libgtkmm, but this is the version linked against the
full X and gtk libs, and not libgtk-dfb version, not sure if we can gain some
this way.

So, altough it is not so small, compared to the current powerpc gtkdi ramdisk,
which is of 19MB compressed, it is rather a negligible size.

As for those who think that having c++ .udebs and related is overkill or
should not be done or whatever (have still a week or so of email to catch off,
and couldn't participate in that irc session), remember, that altough .udebs
are currently used only in d-i, they are prime candidates for use in other
cases where smaller packages are needed, like the embedded case, as was
discussed in Helsinki, and i know of at least one case where they where reused
directly in a small (x86) embedded system.

And finally, about mklibs, i think i remember that the powerpc gtkdi ramdisk
shrank some couple 100 KB when using mkinitrd, which represent only a few
percent of the full size, so i have some doubts we need to worry about this
really.

Now, if Xavier works on a gparted .udeb, using c++ .udeb libraries, more power
to him, and his work should not be sabotaged just because some folk don't see
the interest. If it is disliked in the frame of d-i, well, then we don't
include it or whatever, but at this early stage of the etch release just
saying no-way, and thus stopping potentially useful work is i believe not the
way things should work.

Friendly,

Sven Luther



Reply to: