Re: C++ support for the D-I
On Mon, Dec 12, 2005 at 11:12:56PM +0100, Frans Pop wrote:
> Hello Xavier,
>
> On Monday 12 December 2005 12:04, 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 have seen fairly strong opposition from some people in the release team
> and d-i against the idea of supporting C++ in udebs. The consensus seems
> to be that C++ libs
> - are too heavy for d-i;
Well, compared to the whole graphical set, this is not really a huge problem,
and as said, the .udebs could be usefull in out-of-d-i context too.
> - would introduce another load of dependencies further complicating
> d-i release management (which is complex enough as it is).
They would not be part of the ramdisk image, so the load is less than other
components, and not really all that much trouble when you see the main gtk
stuff anyway. C++ are cause of some nasty transition issues, but i don't think
this would be an additional Release blocker since those issues will be solved
anyway for the release. We only need :
libstdc++ (part of the gcc source package).
libsigc++ (in its own source package)
libglibmm (in his own source package, not depending on the graphic stuff)
libgtkmm (need to generate a new gtk-dfb related build and packages, the most
complicated).
> On the other hand, there is very broad support for graphical (read: more
> user-friendly) partitioning support in d-i. I remember Colin Watson
> suggesting creating cdebconf plugins for specific partitioning tasks. The
> option added this weekend to build plugins out-of-tree should help with
> this.
Indeed,
> I think basing the user interaction on gparted is probably a good idea,
> but developing something new (or at least lighter) using the existing d-i
> environment seems a more realistic approach than just packaging gparted.
Yes, but in this case, packaging gparted was the first step of the plan only,
to gain familiarity with packaging support, .udebs and in general the stuff
involved. I am not sure a full reimplementation in C will be completeable in
the devoted timeframe, so ...
> If you can find a different existing frontend (which should probably also
> use libparted) that can be more easily adapted to the d-i environment,
> that would of course be an alternative approach. However, such a frontend
> would probably still need to be adapted to support selecting mountpoints
> besides only manipulating partitions and formatting filesystems.
Yeah, like QtParted maybe :)
> I'm afraid I have too little experience with partitioning frontends or
> with C/C++ programming to offer more help or comments than this; the
> above is mostly what I've picked up from others (mainly from comments on
> IRC).
Yep, understood, i was the one which suggested this project, and gparted came
naturally, since it is a cool tool, the upstream maintainer is a good guy, and
it is of the gparted frontends i know off the only one based on gtk.
I think it would cost very little effort to have the above libs packaged as
.udebs (altough doko said he didn't care so i doubt it will happen, or
something such, only second hand info here), and have a gparted frontend which
could be used or not, while other stuff is being worked on, if nothing else
this will bring more robustness to our gtk-based framework, and such.
Friendly,
Sven Luther
Reply to: