[Build-common-hackers] Emdebian and debhelper.mk

[Neil Williams]

On Wed, 6 Dec 2006 22:41:36 +0100
Peter Eisentraut <peter_e at gmx.net> wrote:

> Neil Williams wrote:
> > Maintaining patches outside the tree - we've already tried that
> > approach and it is very difficult to maintain. It's far easier to
> > change the rules by which the package is built than to change the
> > system that follows those rules.
>
> Well, I'm afraid that I don't agree with that approach.

All the non-CDBS packages are manageable via debian/rules - it is only
CDBS that needs an external handler because it imports the rules from
static files.

All emdebian needs is a process to skip selected parts of those files.
I don't mind if it's an option to CDBS, just something that allows
emdebian to strip out unwanted content from CDBS packages.

This isn't a debhelper issue, it's a CDBS issue.

I'd much rather not have to maintain an external emdebian CDBS rule
file.

> You need to
> enforce your packaging policy at the lowest common denominator, and
> that is dpkg in this case.

But the one system has to be able to build emdebian and normal Debian
packages - we can't go around patching debhelper because debhelper
won't know when to use which code. Quite often, I'll be building the
same package natively and cross-building sequentially.

The *only* packages that need any further adaption are CDBS packages.
We can handle the rest through a very natural process of patching
debian/rules for each package using a wrapper.

Doing this via debhelper loses granularity and still means maintaining
patches out-of-tree - it just won't work. Been there, tried it.
:-(

> If you don't want to patch dpkg, why don't you write a plugin system for
> it that hooks in some sort of postprocessing?

Why? All I need is a sub-class within CDBS or an option to CDBS.

no-docs would be handy but dh_shlibsdeps also needs to be dropped - it
cannot ever work for a cross-build.

-       dh_installchangelogs $(DH_OPTIONS) $(changelog)
-       dh_installdocs $(DH_OPTIONS) $(docs)
-       dh_installdeb $(DH_OPTIONS)
-       dh_shlibdeps $(DH_OPTIONS) -l$(BUILD_TREE)
+#      dh_installchangelogs $(DH_OPTIONS) $(changelog)
+#      dh_installdocs $(DH_OPTIONS) $(docs)
+#      dh_installdeb $(DH_OPTIONS)
+#      dh_shlibdeps $(DH_OPTIONS) -l$(BUILD_TREE)

As an example, libqof1 uses CDBS and cross-builds quite well except
that the final packages contain AUTHORS, ChangeLog.gz,
changelog.Debian.gz etc. We don't want these files on an embedded
system - the whole OS needs to fit in 30Mb. (Mb not Gb.)
:-)

> If you really don't want to go there, then the next lowest common
> denominator is debhelper.  You can easily patch dh_installdocs,
> dh_installman, etc. to omit the files you don't want

No, because we've tried that and it doesn't work with normal Debian
packages.

> , and your job is
> finished.  Most of the work should already be done for the udeb mode,
> so you can build on that.

udeb is completely separate - udeb don't cross-build.

> So with those two options in hand, I don't see the need to touch cdbs at
> all.

Believe me, this isn't something that has just occurred to me in some
flash, it has been considered and developed over a period of years and
all options have been considered. Emdebian developers (most of whom are
DD's themselves) have discussed the approach with the maintainers of
dpkg, debhelper, devscripts and a host of other DD's and this is the
result - what we call the "composite method". It incorporates the best
of all previous build strategies without the drawbacks of other
approaches.

As far as CDBS is concerned, the process boils down to:
1. Use untouched debhelper and dpkg processes
2. Patch debian/rules before dpkg-* runs or debian/rules itself is run
3. Use a simple version string that identifies the package as
emdebianised
4. cross-build using dpkg-buildpackage -a$arch ...

Support from CDBS is only a case of allowing certain debhelper
processes to be skipped under defined circumstances. That's all I am
requesting.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/build-common-hackers/attachments/20061206/2a16b9c1/attachment.pgp