On Wed, 12 Aug 2009 12:58:53 +0200 Hector Oron <hector.oron@gmail.com> wrote: > But, Neil, what do you think on having a debian/rules which points to > debian/rules.d/$native_rules if DEB_BUILD_ARCH == DEB_HOST_ARCH and > debian/rules.d/$cross_rules if DEB_BUILD_ARCH != DEB_HOST_ARCH? > With this and xcontrol, we might be able to make it possible and easy > for crush 2.0, but as you said it might not worth the time if everything > changes. That's a large change, I'm not sure how it would go down with the rest of Debian and some build systems already use multiple rules files. You still have the problem of who writes and who maintains those rules files. It is arguably better to write *descriptions* of the required changes (via a system based on debian/control) than to write the actual *programming rules* to implement the required changes when the package itself is not built with those rules. We've already done this via patches to debian/rules and xcontrol was a step (in the right direction IMHO) to solve the problems that made patching debian/rules so problematic. Besides, it isn't just debian/rules, dropping functionality commonly means changing lines in debian/*.install files that would otherwise fail to find files that the normal Debian build would create - missing files that will fail the build. There isn't a solution for that problem currently - except patches. Writing a whole new debian/rules.d/ file is actually more work and potentially causes more incompatibilities compared to Debian than just patching debian/rules in the first place because someone has to continually port updates to the main rules file into the copies. We can put only the essential cross-build support code within native vs cross conditionals. The rest needs a different mechanism in order to avoid bit rot. There will still be a case for modified package builds long after multiarch has 100% complete cross-building support - we need packages to be built differently, with different options and different configurations, even different package splits. The question has always been how to implement those changes. Patches are a last resort but the only working method we have now. xcontrol was part of a solution and I'm not entirely sure why it's been killed off or how it will be replaced. 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). 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. > [EXTRA] > Another good point to work on, would be to replace perl scripts from > essential packages with some shell scripts. That's highly selective - unless *all* maintainer scripts can be banned from using perl or even calling perl routines, then the gain of such work is lost. I doubt that *all* perl scripts can be converted to shell. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpURsywDHiRV.pgp
Description: PGP signature