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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
