[Build-common-hackers] rewrite plans

[Tom Huckstep]

On Fri, May 21, 2004 at 07:16:38PM -0400, Andres Salomon wrote:
> 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

I'm surprised to discover that debian/rules files are allowed to be anything
other than Makefiles.  I had always assumed it was some policy matter.

Perl or shell would make me sad, though.  If we're going to change the
language, Python would be wonderful.

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

I'd be inclined to argue that we should move away from debhelper altogether,
from an *interface* point of view.  I think it would be fine to use
debhelper on the backend, but just not let the packager know that we're
doing it.


An important configuration point
--------------------------------

I think it is vital  that CDBS configuration files go in a special CDBS
subdirectory of debian/.  This will promote encapsulation, and make it clear
when something is a CDBS native configuration/data file, and when CDBS is
providing an interface to an external program.  e.g. contrast

- Now
debian/patches (does this belong to CDBS simple-patchsys or dpatch?)

- Future
debian/cdbs-data/patches (this belongs to CDBS simple-patchsys)
debian/patches (this probably belongs to dpatch, or someone who has stolen
its namespace)


Other configuration suggestions
-------------------------------

There are two features that I'd love to see:

1) ~ Zero configuration package builds
2) A sane, useful and extendable external interface

1) 

There should be a class ("...build-autodetect.mk", say) that tries to detect
the upstream build system (Makefile, autotools, whatever), and possibly also
the package maintainer's use of debhelper/dpatch/simple-patchsys etc. stuff
and loads all the appropriate build and install modules.

This would allow a one line debian/rules ("include ...build/build-autodetect.mk")
which could be tried first for all simple packages, before customizing more
heavily.  It would need to be very verbose to allow package maintainers to see
how to customize it exactly to their needs.

2)

Let me explain how I would like to see the external (i.e. the filesystem
layout, not the rules file function calls etc.) interface to CDBS.

In my packages I often have the following structure in debian/:

TODO
dirs
docs
control
pkg-name.doc-base
pkg-name.cron.daily
pkg-name.ppp.ip-up
changelog
init.d
README.Debian
pkg-name.postinst
copyright
pkg-name.manpages

etc. etc., you get the picture, it's a horrible debhelper flat directory
layout.

Why not take advantage of the hierarchical database built in to every UNIX
system (i.e. the file system!), to organise this a bit?  There are two
methods I have thought of that structure the data based on different
concepts:

A) Target file system layout

We could stick these debhelper data files in a subdirectory structure in
debian/ more-or-less as we envisage them being installed, so:

debian/cdbs-fs/etc/cron.daily/pkg-name
debian/cdbs-fs/etc/logrotate.d/pkg-name
debian/cdbs-fs/etc/init.d/pkg-name
(maybe along with another file specifying dh_installinit type parameters)
debian/cdbs-fs/ppp/ip-up/down.d/pkg-name

It is not clear what to do with files like "dirs" and "docs" which contain
lists of files to be installed.  Perhaps this is easier to resolve with
structure B, below.

B) Conceptual layout

This would probably look something more like

debian/cdbs-fs/install/cron/pkg-name/cron.daily
debian/cdbs-fs/install/init/pkg-name/init
debian/cdbs-fs/install/logrotate/pkg-name/logrotate
debian/cdbs-fs/action/manpages/pkg-name
debian/cdbs-fs/action/docs/pkg-name
debian/cdbs-fs/action/dirs/pkg-name
(In the last three cases, text files containing the list of
manpages/docs/dirs)

I prefer this concept, but it will need discussion about the best naming
system for the layout.

I envisage that, initially perhaps permanently, this directory layout will
be traversed by CDBS, which will then call the appropriate dh_ command on
the files it finds.


Please let me know what you think.  I'd appreciate being CC'd on replies.

Tom