Bug#367709: requesting libstdc++ .udeb in order to produce c++ based images based on d-i technology (but not d-i).
Package: tech-ctte
Hi, ...
I am sorry to ask again the help of the technical comittee in such a short
time, but this time it is a true technical issue, altough there is a bit of
the social issues overshadowing it too, by virtue of the folk involved.
Some time back, Xavier Oswald started working on a new graphical partitioner
for g-i, as part of his studie's 'stage' (err, practikum in german, no idea in
english). The original project asked for a reuse of the gparted code base, as
well as integrating the partimage technology.
After some discussion, this was vetoed by the d-i people, who didn't want to
have any C++ stuff in the installer, even though it was probably not going to
make such a size increase. A few other also commented negatively on it, the
gcc maintainer, doko, never even responded to our queries due to that.
As a result, Xavier reimplemented gparted in C, and altough he made progress,
it remains to see if his work will be in time for etch. In any case the idea
of reusing partimage is abandoned because there is too little time to
reimplement it in C, and it is probably a more critical and complicated code
base.
That said, with the advent of g-i, there are other usages of .udeb packages,
and the g-i infrastructure itself leaves the door open to a wide variety of
innovative and interesting applications, not necessarily around the core d-i
technologies.
Among those applications, integrating the new partitioner and a partimage
derivative, would allow for a ghost-like non-d-i standalone image, which would
probably be of interest to many people.
Furthermore, with the inclusion of SDL and some gaming tools previsted for
etch, could lead the way of easy reuse of that technology for standalone
games, usable in small embedded systems, or even some freevo thingy would
allow to create images suitable for a tivo like setup, running entirely from a
flash image and so on.
The applications are many, and portend a very bright future for the .udeb
format, as well as an area of developpment which has typically not been
debian's strongest place, despite meritatory efforts like the emdebian stuff.
So, now that this context is etablished, and i hope i forgot none of it this
time :), i file this bug to request that a libstdc++ .udeb be created, either
by the gcc maintainers (easier and better), or as a patch which the gcc
maintainer would then apply.
This leads the way of a usage of the .udebs format beyond the sole scope of
d-i, and it is envisageable that other libraries become .udebized in the
future, or even stuff like the java vms or whatever else may be usefull in the
semi-embedded space.
I hope to have been clear in this report, and provided good arguments for this
case. I file it now, because the attendance of many people at debconf will
probably make the discussion about this topic easier.
And again, one last clarification, this is not aimed for inclusion into d-i,
as the d-i people have clearly rejected such, and will probably not be
something that will be releasable as part of etch, but would live at the
fringes of it, until a better integration may be possible at the etch+1 stage.
Friendly,
Sven Luther
Reply to: