Re: Crush 2.0 abandoned
Hi,
2009/8/12 Neil Williams <codehelp@debian.org>:
> On Wed, 12 Aug 2009 12:58:53 +0200
> Hector Oron <hector.oron@gmail.com> 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
Reply to: