Bug#367709: requesting libstdc++ .udeb in order to produce c++ based images based on d-i technology (but not d-i).
* Sven Luther (firstname.lastname@example.org) [060517 12:56]:
> 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
Actually, what we miss here is that the actual maintainers opposed this
proposal. AFAIK Sven has asked it as part of the d-i section, and of
course, if it is not used by the installer, there is no reason to
provide it inside of the d-i udeb section (btw the only one we currently
What we need if it should be used outside of d-i:
- A clear consensus of the embedded people or so to use udebs (AFAIK
there is no consensus about that right now, and even not discussed out
- Asking the relevant maintainers (that is *not* the d-i team) to
- add other udeb section(s), by the ftp-masters
- asking the maintainer to add non-d-i-udebs
So, I propose the following conclusions from us:
1. Sven Luther asks us to enforce the maintainer to add an udeb for
libstdc++ which is not used in debian-installer.
2. There is no finished discussion whether embedded people really want
udebs, and the technicall committee is not the right place for detailed
design work (Constitution 6.3.5).
3. The technical committee makes decisions only as last resort
4. The only existing udeb section is intended for the installer; the
ftp-masters were not even asked to add a new section.
THE COMMITTEE CONCLUDES
1. As the udeb is not intended for inclusion into debian-installer, we
agree with the maintainer's decision to not add an udeb in that section.
2. As the maintainers were not asked for adding another udeb section, we
don't make any decision about this.
3. We encourage the embedded people to continue there discussion about
the optimal format is for them, and to set up experimental environments
for their first tests by themself.