[Build-common-hackers] rewrite plans

[Colin Walters]

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

On Fri, 2004-05-21 at 19:16, Andres Salomon wrote:
> 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:
>=20
> * Consistent hook naming. =20

Would be nice, yeah.

> * Verbosity setting=20

Yep.

Both of the above seem doable without a rewrite though.  Just have the
old hook names depend on the new ones.  Probably put them in a separate
-compat.mk file which is included by default for cleanliness.

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

Don't we already support this with DEB_BUILDDIRS or something?

> * Support for -source packages.=20

Sounds doable without a rewrite.  We already recognize -debug and -udeb.

> * Support for -udeb packages.  Same as -source packages; CDBS should
> automatically handle debhelper stuff for udebs.

We already have this, although as I understand it isn't great.  I wrote
it before debhelper had udeb stuff though.

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

Yes...this is very tricky.

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

I'm not sure about automatically modifying the Build-Depends line.  We
could probably grep for things that seem likely and warn if they're not
present.  But I wouldn't add them automatically, since they could just
be part of another dependency, and calling out to apt or whatever sounds
pretty evil :)

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

Yeah.

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

One of my original goals was to have the cdbs core be integrated into
dpkg, so bits and pieces (e.g. variables) could be used by all
packages.  I think in order to make that useful to the current package
set, cdbs should stay in gmake.


--=-EtsjzNQ59ny1eO9o7Dov
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)

iD8DBQBAx717OIkJWWp2WGURAurcAJ4u4XgmijY0GxCBPKdZLKfStq2rvACfcwf1
NJfdgMdX5nX0ZeyT6II9p9s=
=uy2I
-----END PGP SIGNATURE-----

--=-EtsjzNQ59ny1eO9o7Dov--