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

[Jonathan Maw <jonathan maw codethink co uk>]

On 2017-07-06 12:32, Tristan Van Berkom wrote:
> On Thu, 2017-07-06 at 11:27 +0100, Jonathan Maw wrote:
> > 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 ?

Hi Tristan,

What benefits do you see in giving the split domains the naming scheme 
<element_name>-<package_name>?
As I understand it, split-rules are element-specific (unless they're 
inherited from projectconfig), so
they won't cause confusion that way).
I suppose there might be benefit in that it makes it easier to identify 
which split-rules are packages
when split-rules are hand-written (hence have been merged with the 
defaults, instead of overriding them),
but I suspect that wasn't the point you were referring to.

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

That should be doable. I'm not so sure about it, because in my 
experience not every package had md5sums.
On the other hand, I suppose there's no harm in generating them from the 
package, and it means less that I have to explain in the data model.

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

I take it you're referring to versioning of the public data, so that we 
can handle
changes to the format sensibly?

I haven't given it much thought. I suppose there are two options:

1) Add a version number to the "bst" domain.

   i.e. public.bst.version is defined in the defaults, and when we alter 
the format for public data, that version goes up.

2) Add version numbers to the subdomains in "bst".

   i.e. there'd be public.bst.split-rules.version, 
public.bst.dpkg-data.version and public.bst.package-scripts.version 
defined in the defaults.

I'd prefer version 2), since that way someone who wants to add something 
completely separate doesn't have to comprehend the entire history of 
public data formats.

Best regards,

Jonathan