Proposed public data fields for dpkg build and deploy elements

[Jonathan Maw <jonathan maw codethink com>]

Hi,

I'm working on two buildstream plugins:
* A dpkg-build plugin which takes dpkg sources (i.e. source trees with 
debian/rules and debian/control) and produces an artifact.
* A dpkg-deploy plugin which takes an artifact (and appropriate public 
data) and generates debian packages (.deb files)

Because there is insufficient information to generate a debian package 
from just the files, I am reading the public data attached to the 
artifact.

The fields I am currently using are:

bst.split-rules
===============

I take the keys to this dict (called split domains, iirc) as the names 
of the packages, and the corresponding values as the list of files to 
include in the package, e.g.

public:
  bst:
    split-rules:
      foo:
      - /usr/bin/bar
      - /etc/baz
      quux:
      - /sbin/baz
      - /var/frob

would indicate a package called "foo" and a package called "quux"

bst.dpkg-data
=============

dpkg-data is a dict with the keys as package names, and the values being 
metadata specific to creating debian packages.

Note that below, <package> is the name of the package.

bst.dpkg-data.<package>.control
---------------------

The text of a debian control file.

This will be reconstituted into a DEBIAN/control file for each package.

e.g.
public:
  bst:
    dpkg-data:
      foo:
        control: |
          Package: bsdgames
          Architecture: any
          Depends: ${shlibs:Depends}, ${misc:Depends}, wamerican | 
wordlist
          Provides: adventure
          Description: collection of classic textual unix games
           This is a collection of some of the text-based games and 
amusements that
           have been enjoyed for decades on unix systems.
           .
           It includes these programs: adventure, arithmetic, atc, 
backgammon,
           battlestar, bcd, boggle, caesar, canfield, countmail, 
cribbage, dab,
           go-fish, gomoku, hack, hangman, hunt, mille, monop, morse, 
number,
           pig, phantasia, pom, ppt, primes, quiz, random, rain, robots, 
rot13,
           sail, snake, tetris, trek, wargames, worm, worms, wump, wtf



bst.dpkg-data.md5sums
---------------------

A dict with the key indicating the file path, and the value is the 
md5sum of that file,
e.g.

public:
  bst:
    dpkg-data:
      foo:
        md5sums:
          /usr/bin/foo: 19deed71b16abc86264c5c24a9359b1f
          /var/lib/baz: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


The dpkg-deploy element reconstitutes this into a DEBIAN/md5sums file as
"<md5sum>  <path>"

bst.package-scripts
-------------------

A dict containing the fields "preinst", "postinst", "prerm" and 
"postrm".
It is in a separate section as many packaging systems make use of 
install scripts.

public:
  bst:
    package-scripts:
      foo:
        postinst: |
          #!/bin/sh
          /sbin/ldconfig
        postrm: |
          #!/bin/sh
          /sbin/ldconfig


The dpkg-deploy element reconstitutes these scripts into a 
DEBIAN/<scriptname> file.

===

Does this sound like a sensible setup?

Is there somewhere in the source code that I should document this?

Thanks,

Jonathan