Possible framework for `debmake replacement'
Here's my little pseudo-constructive bit. I don't imagine this is good
enough to be taken as is by any means, even if people do agree, but I
have a few ideas floating around in my head which nobody seems to have
come up with yet, at least not in this exact form. So now I finally have
a little spare time, here goes. :)
Disclaimer: I know absolutely nothing about multi-binary packages, so
this may or may not get around some of the deficiencies of debmake in
that area. I have not tried to think about this, though; it will have to
be looked at by somebody who understands this sort of thing if people
think it's worthwhile.
Summary
-------
It appears, to me at least, that debmake performs a number of functions:
* Makes it easier to make a package from scratch, by basically being an
intelligent template.
* Makes it easier to keep a simple debian/rules file up to date, by
automating a lot of it in a transparent manner.
* Makes it easier for packages to track standards.
But there is no reason why these functions should necessarily be a part
of the same package. Therefore I propose the following structure:
* A template, possibly intelligent, which automatically constructs a
debian/rules file, together with possible others such as the
installation scripts. These files should be editable by the package
maintainer to a certain extent having been created, although we don't
necessarily need to include every single simple command.
* A helper program(s), which is called from the debian/rules file as
many times as necessary in order to perform the package
construction.
* A deblint-type tool which checks the constructed package.
Details
-------
The core of this package would be the helper program(s), which for the
sake of this proposal will be a set of programs with the prefix `dmake-'.
So for example, dmake-binary would install one or more binaries,
according to the current standards (eg, stripped). A possible, probably
partial, list of these follows:
binary: installs executable binaries
library: installs shared libraries
doc: installs documentation. This would take a switch to specify the type
(info, manpage, etc), and would install in the appropriate place and
compress if necessary (overridable). Alternatively this could be
split into seperate programs for each type. This would *not*
generate, for example, calls to install-info in the relevant
installation scripts; this is the responsibility of the template and
the package maintainer.
instscript: installs preinst, postinst, etc scripts. There is no
provision for generation of these; this should be done by the
template at package creation time.
cronscript: installs /etc/cron.* scripts in the same manner.
data: installs data in /usr/lib/packagename, or somewhere else. By my
understanding, no processing should be done on this data, although
it may for instance be md5checksummed at this stage.
supplemental: anything else which I have forgotten. :) This is for much
the same reason as the data target above.
All these programs install by default in the /usr hierarchy (/usr/bin,
/usr/lib/packagename, /usr/info, and so on), although this should be
overridable using a commandline option. For multiple-binary packages, an
option to specify the package being built could be added.
--
Then we have a rules template. We will assume here that this template is
intelligent, and therefore an executable, named for example dmake-rules.
It should also be the case that the package is compilable without the
prescence of this template, although the helpers above should be present
on all systems wanting to compile packages. This template must also be
idempotent, and so and configuration used by the intelligent part of it
should be stored, for example in the debian directory. If the maintainer
changes any of the code in debian/rules produced by this template, it is
her responsibility to either (a) not run it again, or (b) clean up
herself after rerunning.
The idea is that the volatile bits of code should be in the helpers
above, and this template should be more-or-less static, providing a base
for a new package. In this respect, it acts a little like debstd, except
that it is run once at package creation time, and is from then on
basically obsolete.
There should also be another template along similar lines, for example
dmake-scripts, which constructs things like sample preinst and postinst
scripts given configuration files similar to debmake's. Again, no
provision is made for it to be run after these scripts have been
modified.
These two templates are split to allow easier rerunning of one without
the other. However, some of the configuration files may be shared, for
example specifying GNU info documents to be installed.
--
The final part of the package is a checker, which can be run by the
package maintainer to ensure that their package conforms to standards.
>From what little I understand of deblint, this is the sort of idea,
although the interface maybe ought to be standardised.
Examples
--------
A simple package, foo, containing two executables foo and bar, with
manpages in the subdirectory man/ of the original source tree; a GNU info
document; and some static data in /usr/lib/foo. It also creates a logfile
in /var/log, which is to be rotated weekly.
First, a file debian/docs is created specifying (in some as yet to be
determined format) the documentation files, together with any associated
information. For example, something like:
--debian/docs
man/foo.1:man
man/bar.1:man
foo.info:info:Editors:Little editor for little people
copyright:doc
--
--debian/cron.weekly
# rotate the logfiles
--
Then the package is compiled (to find the binaries etc), and the
templates run. This produces:
--debian/rules
.
.
.
binary-arch:
dmake-binary foo bar
dmake-doc -tman man/foo.1 man/bar.8
dmake-doc -tinfo foo.info 'Editors' 'Little editor for little people'
dmake-doc -tdoc copyright
dmake-instscript debian/cron.weekly
.
.
.
--
together with debian/postinst to install the info documentation
--debian/postinst
install-info blah blah blah
--
The debian/rules file would then be edited by the maintainer, to include
the line
dmake-supplemental -r keys/ filetypes.def
to install the named directory and file into /usr/lib/foo.
Conclusion
----------
This seems to me to provide a useful way of hiding some of the
implementation details, which keeping them (a) accessible and (b) not too
well buried. It still needs a bit of work---in particular, the config
files should be defined, and the exact steps done by the template, and it
would also be nice to be able to run it on an edited debian/rules file
etc, but it should provide some food for thought.
I hope this turns out to be useful. I would like to make it clear,
though, that I am *not* volunteering to actually write this tool, but I
had some ideas and it seemed stupid not to share them. If there're more
comments I'm quite happy to look after this document, though, if people
think that is worthwhile.
Enjoy,
&E
--
Andy Mortimer, andy.mortimer@poboxes.com
http://www.netforward.com/poboxes/?andy.mortimer
Finger asm21@asm21.emma.cam.ac.uk for PGP public key
--
When the sunset's glow drifts away from you you'll never know
If any of this was really true at all.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: