Re: Proposed public data fields for dpkg build and deploy elements

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Thu, 2017-07-06 at 11:27 +0100, Jonathan Maw wrote:
> 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.

Thanks for the writeup !

Comments in line below...

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

Surely you must mean, the package names would be:

  "<element-name>-foo"
  "<element-name>-quux"

Where <element name> is Element.normal_name ?


> 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

Looks sensible to me...


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

This I am skeptical about, would it not be better at deploy time to
just generate this from the files going into the package ?


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

Okay, I have some concerns about how this format for packaging
scriptlets will work with other packaging systems, but to avoid
blocking your progress, lets try to address these concerns separately.

Instead, can you outline a plan for revisioning of this data ?

What I'm mainly concerned with, is if we eventually want to use this
data for another packaging system but share the same scriptlets to
deploy to multiple packaging systems, what happens then ?

  A.) The dpkg-deploy element should probably understand what revision
      the scriptlets were written for, and behave in a backwards
      compatible way.

  B.) A potential new package deployment element, say RPM, which cannot
      handle the old version, should be able to bail out with an error
      when detecting an incompatible 'package-scripts' syntax

Cheers,
    -Tristan