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

[Jonathan Maw <jonathanmaw codethink com>]

On 2017-07-07 09:12, Tristan Van Berkom wrote:
> 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

Hi Tristan,

Currently, it is impossible to generate a "devel.deb" package because 
there's no
"control" metadata for the "devel" split domain.
I see what you mean, though. In future, if we want to generate debian 
packages for
ordinary elements, splitting them along -devel, -doc and -debug lines 
would require
a fair amount of manual effort to re-define the split-rules.

Are we interested in generating packages that aren't prefixed with the 
element name?
i.e. python3-defaults-debian produces the idle3 package. Would we still 
want to generate
idle3 from python3-defaults-debian, or would we be expect 
python3-defaults-debian-idle3?