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

Bug#367709: marked as done (requesting libstdc++ .udeb in order to produce c++ based images based on d-i technology (but not d-i).)

Your message dated Tue, 26 Jun 2007 10:01:04 +0100
with message-id <18048.54736.729549.700963@davenant.relativity.greenend.org.uk>
and subject line Closing this one for the last time
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
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

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

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.


Sven Luther

--- End Message ---
--- Begin Message ---
As previously discussed, the state of this bug has been decided by the
appropriate people:

The relevant maintainers decided according to 3.1(1) that they did not
agree with the request.  Technical Committee have decided not to
exercise their power in 6.1(4) to overrule this decision.

I am therefore closing this bug report.  Please do not reopen it.


--- End Message ---

Reply to: