Raul Miller wrote:
Have you talked to the di people about this issue? Have they raised any objections? If so, what are they? (We should get involved if you feel that they are making a choice which is technically incorrect and which you can't resolve directly.)
I've had this discussion with Sven a few times on IRC and even though I'm not a particularly active d-i developer, I think I can help answer your questions.
udebs are made for one particular purpose: supporting d-i. They're not made as a general "small and stripped system" approach. They're free to violate Debian policy (by not shipping documentation, eg), but they should support d-i. Having other packages packaged as udebs makes testing migration harder and can in some cases cause problems for the installer, such as needlessly installing udebs due to priority.
The specific request here is not just for a udeb, but for introducing C++ into the realm of d-i. I think I can speak for the d-i team when I say that they don't even want to tempt people into writing code using C++ for d-i (due to space issues as well as symbol mangling issues, etc), so in the same way that a suggestion to include perl, python, ruby or lua udebs would be opposed, a request to include C++ udebs is opposed.
I believe Sven would be better served by either using standard debs (and udebs, as appropriate) and mangling those, then put them into a firmware image or invent another format of debs-but-not-debs and use those as a basis for same.
- tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
