[Build-common-hackers] rewrite plans
Fri, 21 May 2004 19:16:38 -0400
Ok, since I've gotten a few emails and such about the rewrite I'm
currently working on, I figured it would be good to get a discussion
going. So, to start off, here are my planned features:
* Consistent hook naming. Instead of random hooks, I have code (which I
need to clean up and commit to my arch repository; more on that later)
which uses the following 4 targets: prepare, build, package, and clean.=20
Each target has 3 phases; pre-, post-, and the main target. So, for
example, the clean process would go: pre-clean, clean, and then
post-clean. That ends up being 12 phases. On top of that, each phase
has -arch, -indep, -common, and /$(curpkg). So, a hook can be added for
pre-clean-common, to be run for all packages; or, one could add
* Verbosity setting that prints out each hook name as it's excuted.=20
This, along w/ the previous feature, should alleviate the need for
package maintainers to have to look through CDBS build rules when trying
to figure out where a hook should go. For example, if I want to add a
dh_kpatches call for a kernel-patch-foo package, I can set DEB_VERBOSE
:=3D 1, and then build the package. As each hook is called, it would
print out what's being run. When I see post-package-common call
something that needs to be called after dh_kpatches, I know that I can
add a hook to package/$(curpkg) to have it call dh_kpatches first.
* Support for multiple build directories. This would create directories
in the pre-prepare hook; for example, pre-prepape/apache2-mpm-prefork
would create debian/build/apache2-mpm-prefork. This is one way of doing
multi-builds; it is good for smaller packages.
* Support for -source packages. This would handle creation of -source
packages, for larger packages that need multi-build support. php4 is a
perfect example, here; currently, its build-deps are rather obscene. By
making a php4-source package, and each SAPI having its own source
package that just build-deps on php4-source, things would be made
easier. Widespread usage of this sort of thing would also alleviate
migration of packages into testing. CDBS should be smart enough to
recognize a -source package and prepare the package without any
user-supplied hooks (debian/patches would be used to modify the source
tree before creating the package).
* Support for -udeb packages. Same as -source packages; CDBS should
automatically handle debhelper stuff for udebs.
* Generation of control files. A control.cdbs might have CDBS variables
for SONAMEs, so that the line "Package: libfoo$(CDBS_SONAME)" would be
changed to "Package: libfoo4" (if SONAME=3D=3D4) in the generated control
file. This doesn't have to be for just file contents; it can also be
for files themselves. For example, libfooCDBS_SONAME.install.cdbs can
be turned into libfoo4.install. This sort of thing is useful for
packages like gstreamer, and kernel packages.
* Automatic build-dep handling. If control files are being generated,
there's no reason why we can't add "cdbs (>=3D 4.0.0), debhelper (>=3D 4.2)=
to a Build-dep line. There are lots of other possibilities for handling
things more cleanly than we currently do, as well.
* And, of course, all the current CDBS features we've come to enjoy; 4
line debian/rules, auto-patching, the ability to easily override and
extend default behavior.
I had started implementing this in gmake; however, as jbailey pointed
out, there's no reason why this can't be done in shell. I'm even
inclined to do it in perl, but I'll have to play w/ it a bit. I don't
have anything committed to my arch repository yet, as the code isn't in
a usable state yet.
There are places where my planned feature list overlaps (in
functionality) with debhelper. For example, modification of
debian/control. One could argue that debhelper should be doing this
instead of CDBS; however, there's no reason we can't switch to doing it
in debhelper later on.
Anyways, comments, thoughts, and suggestions are appreciated. Possible
support for other package types (-modules, kernel-patch-) is is, of
course, a possibility; as long as CDBS stays modular.
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----