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 17:49 +0100, Jonathan Maw wrote:
> 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.

I have a feeling we might just be saying the same thing with different
words (but I'm not sure).

So yeah, lets say that nobody set any custom metadata, and one attempts
the deploy a hand full of build element artifacts as debian packages.

By default, we have the standard domains such as 'devel', 'doc',
'debug' etc.

Certainly the intention here is not to generate a bunch of dpkg
packages all with the name 'devel.deb', instead we want to be
generating packages named '<element-name>-devel.deb' etc, so that by
default we are producing sensible package names, right ?

Cheers,
    -Tristan