Otavio Salvador wrote:
Sven Luther <[EMAIL PROTECTED]> writes:
Is someone still working on this? Would a gparted-like partitioner be
useful for post-etch? (That's basically a lot of GTK programming, i
could work on it too)
Another solution is to use gparted and the C++ libraries which go with it. I
know that there is a dogma of not using c++, but given the development ongoing
on gparted, and that we would basically need to do fork all that development
if we want to do our stuff.
Adding C++ libraries will add more or less 1MB to the image.
I'm not sure that will be just that the needed space for the whole C++
code to be in d-i.
From d-i point of view, I think it (use of another partitioner) would
make things harder to evolve together since the new features would
need to be add in partman and <your pet graphical partitioner here>.
Is either that or having a great installer which sucks just because we
have a _really_ crappy partitioner. And I don't think anybody can argue,
while being serious, that we didn't have lots of reports complaining
about the partitioner being crappy (I am not sure, but I think this was
one of the reasons behind partitioning recipes).
I don't know what others thing about this but I think would be better
to have a common partitioner for all frontends to avoid that kinda of
complication in D-I release and development.
In that case I guess Xavier just wasted his time on the C port of gparted.
AFAIR, the reason why C++ is not supported in D-I is because the
maintainer of libc++ didn't answer to the request to create udebs... and
not having libc++ in D-I just because the maintainer didn't created
udebs is another proof that Debian has a lot of work to do WRT
communication.
--
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
