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

Re: Crush 2.0 abandoned



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: pgpMkrn4WcJ3y.pgp
Description: PGP signature


Reply to: