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

Re: C++ support for the D-I



On Monday 12 December 2005 12:04, Xavier Oswald wrote:
> So, what do you think about integrating C++ in the D-I or we should
> look about another partitioning tool written in C ?

I noticed a discussion today on the #d-boot channel that I feel
covers very well the reservations felt by some people about
including C++ based components in d-i. It also touches on the
importance of integration with existing partman.

Although the C++ libs may not be extremely large, they are still
an addition to the memory requirements for d-i while it is still
relying completely on RAM to run (no swap available yet).

Although initrd size and memory size has not been a primary consideration
up to this point, I do expect that it will be a major area we'll work
on in the run-up to the release of Sarge, after the font and udeb
dependency issues have been solved.

Only irrelevant lines removed and some typos fixed.
<[-oskar-]> Kamion, I'm working on the partitioning tool for the D-I..
I think, you develop for Debian and Ubuntu too
<Kamion> yes ...
<[-oskar-]> Kamion, i was asking to have information what you use for
this part in Ubuntu and where can i get informations..
<Kamion> we use partman, same as Debian
<[-oskar-]> Kamion, but it was something develop with gparted.. no ?
<Kamion> in the live installer that we have planned, we'll be using a
combination of partman run through a debconf filter, and gparted
<Kamion> (but that won't be running within d-i, so we don't have issues
with libstdc++ in a minimal environment or whatever)
<Kamion> gparted will only be for the advanced partitioner though
<[-oskar-]> Kamion, I'm trying to build udeb from libstdc++
<Kamion> yes, I've already given my opinions on that :P
<Kamion> but never mind
<Kamion> waldi's also said that library reduction doesn't currently work
on C++, so I hope you're taking that into account
<[-oskar-]> but this libs doesn't take lots of mem...
<[-oskar-]> Kamion, what do you think about the answer of svenl on
debian-boot list ?
<Kamion> takes a hell of a lot more than most of the other libraries we
reduce :P
<Kamion> I'm not up to date with debian-boot, and in general I find
svenl's comments very difficult to read (something about language
choice I suspect) so I don't know
<[-oskar-]> Kamion, so your mind is a reimplementation of gparted in C
or ... ?
<[-oskar-]> Kamion, lol
<Kamion> I don't have an opinion on it; personally I would much rather 
have
GTK custom widgets on top of partman, if possible using design from 
gparted
<Kamion> but I'm not involved enough in the graphical installer any more
to really care
<Kamion> (and unless I actually write code for it, my personal feelings
don't really count for all that much)
<[-oskar-]> Kamion, ok, but as i think partman is not very clean 
coded ... ?!
<Kamion> a lot of the rest of d-i integrates tightly with partman
<Kamion> if you try to ignore partman, it becomes your responsibility to
pick up bits of that integration
<Kamion> I don't think partman is that bad; it's slow, yes, but we could
probably fix a lot of that by building echo and test into the busybox
shell (echo's already done upstream, AFAIK); and it needs some 'set -e'
love for better error handling
<[-oskar-]> Kamion, I was thinking about something like: keep partman and
use gparted just for manual partition of the device
<Kamion> but it's got a lot of important logic in it that I would not like
to see having to maintain twice
<Kamion> that's probably doable, but you still have to cope with things
like the partman-newworld/yaboot-installer integration for newworld boot
partitions on powerpc
<Kamion> similar on other architectures, and that all applies to manual 
mode too
<Kamion> this is why I'd rather see the widgets pulled out and used
<[-oskar-]> hmm
<Kamion> it's been quite useful for quick development to have partman 
written
in an interpreted language that you can hack on the fly inside d-i
<Kamion> gtk shell bindings would probably be just too evil :-), but it 
seems
that it would be possible to have cdebconf call bits of widgetry
<Kamion> and then we get to avoid reintroducing an unknown number of bugs
that have been dealt with in partman
<Kamion> and if we fix things in one installation mode, we get to fix them
in the others for free
<Kamion> etc.
<[-oskar-]> hmm ok
<[-oskar-]> i see

Attachment: pgpskOYvJk7cO.pgp
Description: PGP signature


Reply to: