Hi, 2009/8/12 Neil Williams <[email protected]>: > On Wed, 12 Aug 2009 12:58:53 +0200 > Hector Oron <[email protected]> wrote: > > IMHO the only real solution is to merge our changes into the normal > build system files that the maintainer routinely edits and reads. > Adding a file that the maintainer doesn't actually have to care about > is a recipe for bit rot. It's going to be hard enough persuading some > maintainers to care about the sections of code in debian/rules that are > not activated within a normal build. > > That is why things like build modifications *must* support being > implemented in *NATIVE* builds, not purely cross-build. I've done most > of the bugs to implement cross-build support and the common complaint > from the maintainers is "but how do I test that your patch is > correct?", with the answer: "umm, you can't without installing a whole > bunch of specialised packages and using a few specialised scripts > instead of dpkg-buildpackage". Maintainers need to be able to test these > modifications and maintain them in working order (as well as understand > - and document - why they need to be retained).
I would like to point Anibal had the desire to work or at least have a look to teach build&test systems about cross building, so he can test his packages will work on the openmoko when cross building. CC: anibal, because I am not sure he is subscribed to debian-embedded. > Supporting things like modified busybox configs, dropping ldap from > gconf etc., means allowing maintainers to *TEST* what these things do > in a normal Debian build operation and whilst having to do as little as > possible to actually switch between build configurations. Tests also > need to be done with the normal tools used by the maintainer, wherever > possible. Native implementations also mean that our changes are quicker > for us to test too - because most changes are to be made equally > across all build architectures. We can use amd64/i386 chroots for > testing instead of having to copy the armel package into a rootfs or > similar. > > DEB_VENDOR is the best channel for these kinds of changes, yet there is > a paradox that putting the changes into the hands of the maintainers > also means that the scope of the changes can be limited by the number > of options that maintainers are willing to test. The bigger the > package, the longer the build but the more possible options can exist > and the higher the workload. I was pondering the answers to these > problems before I became ill and I haven't got a solution yet either. > > It's a choice between either allowing all possible options and letting > most of the possible combinations be utterly broken or limiting the > options to ones where Debian maintainers can be reasonably confident > that things should work. The Debian maintainer knows the package better > than we do, especially the history of the bugs, I think we have to put > things in their hands and give them the tools to test things so that > they can maintain the changes in their own way. When we hack around in > packages, there is a significant risk of causing regressions within the > package - we need to work with the maintainers to avoid that risk. > -- Héctor Orón -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
