[Build-common-hackers] rewrite plans

[Andres Salomon]

--=-+GFMJJrXp21I9VbiaJcN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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
pre-clean/libfoo-dev.

* 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.


--=-+GFMJJrXp21I9VbiaJcN
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)

iD8DBQBAroz178o9R9NraMQRAjJtAJ4kMO9Lwyz22NUnmYb9GDjgtvzdtwCfTVRu
Bl3G756sVOSOSQYyK17CjEk=
=TGeo
-----END PGP SIGNATURE-----

--=-+GFMJJrXp21I9VbiaJcN--