Patchwork [RFC,-,WIP,v2,01/10] conf-files: New recipe to create single recipe for config files

login
register
mail settings
Submitter Saul Wold
Date June 12, 2014, 5:56 a.m.
Message ID <37280175766b34129a22d2602f057511e90263b1.1402552609.git.sgw@linux.intel.com>
Download mbox | patch
Permalink /patch/73623/
State New
Headers show

Comments

Saul Wold - June 12, 2014, 5:56 a.m.
This recipe will create 1 package for config files, we could optionally add
a bbclass file to ensure consistency with RRECOMMENDS_ = =conf

This is a work in progress, the do_install might even beable to automagically
generated.  We don't want to create a bbclass for these since it will cause
the actual recipe/packaging to become machine specific, using this recipe will
ioslate that.

[YOCTO #4011]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/classes/conf-files.bbclass               |  3 +
 meta/recipes-bsp/conf-files/conf-files_1.0.bb | 84 +++++++++++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 meta/classes/conf-files.bbclass
 create mode 100644 meta/recipes-bsp/conf-files/conf-files_1.0.bb
Otavio Salvador - June 12, 2014, 1:57 p.m.
On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
> This recipe will create 1 package for config files, we could optionally add
> a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
>
> This is a work in progress, the do_install might even beable to automagically
> generated.  We don't want to create a bbclass for these since it will cause
> the actual recipe/packaging to become machine specific, using this recipe will
> ioslate that.
>
> [YOCTO #4011]
>
> Signed-off-by: Saul Wold <sgw@linux.intel.com>

I think the configuration file, nowadays, already made those machine
specific in every BSP which has those overriden so I don't see why use
a single recipe to provide several configuration files.

I think it will be confusing and this recipe will fast grow.
Richard Purdie - June 13, 2014, 8:06 a.m.
On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
> > This recipe will create 1 package for config files, we could optionally add
> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
> >
> > This is a work in progress, the do_install might even beable to automagically
> > generated.  We don't want to create a bbclass for these since it will cause
> > the actual recipe/packaging to become machine specific, using this recipe will
> > ioslate that.
> >
> > [YOCTO #4011]
> >
> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> 
> I think the configuration file, nowadays, already made those machine
> specific in every BSP which has those overriden so I don't see why use
> a single recipe to provide several configuration files.
> 
> I think it will be confusing and this recipe will fast grow.

There are a few good reasons to do this. 

Machine customisation is spread around a whole load of different recipes
at the moment and its hard to obtain a good view of what files are
available and which ones a BSP author may need to provide.

Its rather ugly to have to provide and maintain multiple bbappend files
with rather ugly syntax within them. Its also rather inefficient from a
build process standpoint to have 15-20 recipes just packaging
configuration files.

The intent isn't to mandate *every* config file should be in this
recipe, you will as now be able to add additional ones. Where we see the
same files being added in many layers, adding something common and
shared makes sense though.

It should in some cases also allow the "core" recipe to stop being
machine specific and shared, improving build efficiency. There is little
point in a recipe becomming machine specific over a config file.

So I'd consider this move a consolation which we can improve over time.
For new users I'd suggest that one more common place for the majority of
machine specific files would be more understandable too.

Cheers,

Richard
Otavio Salvador - June 13, 2014, 3:30 p.m.
On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
>> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
>> > This recipe will create 1 package for config files, we could optionally add
>> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
>> >
>> > This is a work in progress, the do_install might even beable to automagically
>> > generated.  We don't want to create a bbclass for these since it will cause
>> > the actual recipe/packaging to become machine specific, using this recipe will
>> > ioslate that.
>> >
>> > [YOCTO #4011]
>> >
>> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
>>
>> I think the configuration file, nowadays, already made those machine
>> specific in every BSP which has those overriden so I don't see why use
>> a single recipe to provide several configuration files.
>>
>> I think it will be confusing and this recipe will fast grow.
>
> There are a few good reasons to do this.
>
> Machine customisation is spread around a whole load of different recipes
> at the moment and its hard to obtain a good view of what files are
> available and which ones a BSP author may need to provide.
>
> Its rather ugly to have to provide and maintain multiple bbappend files
> with rather ugly syntax within them. Its also rather inefficient from a
> build process standpoint to have 15-20 recipes just packaging
> configuration files.
>
> The intent isn't to mandate *every* config file should be in this
> recipe, you will as now be able to add additional ones. Where we see the
> same files being added in many layers, adding something common and
> shared makes sense though.
>
> It should in some cases also allow the "core" recipe to stop being
> machine specific and shared, improving build efficiency. There is little
> point in a recipe becomming machine specific over a config file.
>
> So I'd consider this move a consolation which we can improve over time.
> For new users I'd suggest that one more common place for the majority of
> machine specific files would be more understandable too.

I understand and mostly agree. However I don't want to have a recipe
with 20 configuration files where I'd need just two.

So I think we'd need to have a way to 'enable/disable' each
configuration override. Does it makes sense?
Richard Purdie - June 13, 2014, 3:40 p.m.
On Fri, 2014-06-13 at 12:30 -0300, Otavio Salvador wrote:
> On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
> >> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
> >> > This recipe will create 1 package for config files, we could optionally add
> >> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
> >> >
> >> > This is a work in progress, the do_install might even beable to automagically
> >> > generated.  We don't want to create a bbclass for these since it will cause
> >> > the actual recipe/packaging to become machine specific, using this recipe will
> >> > ioslate that.
> >> >
> >> > [YOCTO #4011]
> >> >
> >> > Signed-off-by: Saul Wold <sgw@linux.intel.com>
> >>
> >> I think the configuration file, nowadays, already made those machine
> >> specific in every BSP which has those overriden so I don't see why use
> >> a single recipe to provide several configuration files.
> >>
> >> I think it will be confusing and this recipe will fast grow.
> >
> > There are a few good reasons to do this.
> >
> > Machine customisation is spread around a whole load of different recipes
> > at the moment and its hard to obtain a good view of what files are
> > available and which ones a BSP author may need to provide.
> >
> > Its rather ugly to have to provide and maintain multiple bbappend files
> > with rather ugly syntax within them. Its also rather inefficient from a
> > build process standpoint to have 15-20 recipes just packaging
> > configuration files.
> >
> > The intent isn't to mandate *every* config file should be in this
> > recipe, you will as now be able to add additional ones. Where we see the
> > same files being added in many layers, adding something common and
> > shared makes sense though.
> >
> > It should in some cases also allow the "core" recipe to stop being
> > machine specific and shared, improving build efficiency. There is little
> > point in a recipe becomming machine specific over a config file.
> >
> > So I'd consider this move a consolation which we can improve over time.
> > For new users I'd suggest that one more common place for the majority of
> > machine specific files would be more understandable too.
> 
> I understand and mostly agree. However I don't want to have a recipe
> with 20 configuration files where I'd need just two.
> 
> So I think we'd need to have a way to 'enable/disable' each
> configuration override. Does it makes sense?

I'd have thought our standard inheritance would apply so that if you
didn't append a machine specific version, the default would be used?

Cheers,

Richard
Mark Hatle - June 13, 2014, 4:10 p.m.
On 6/13/14, 10:40 AM, Richard Purdie wrote:
> On Fri, 2014-06-13 at 12:30 -0300, Otavio Salvador wrote:
>> On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
>>>> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw@linux.intel.com> wrote:
>>>>> This recipe will create 1 package for config files, we could optionally add
>>>>> a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
>>>>>
>>>>> This is a work in progress, the do_install might even beable to automagically
>>>>> generated.  We don't want to create a bbclass for these since it will cause
>>>>> the actual recipe/packaging to become machine specific, using this recipe will
>>>>> ioslate that.
>>>>>
>>>>> [YOCTO #4011]
>>>>>
>>>>> Signed-off-by: Saul Wold <sgw@linux.intel.com>
>>>>
>>>> I think the configuration file, nowadays, already made those machine
>>>> specific in every BSP which has those overriden so I don't see why use
>>>> a single recipe to provide several configuration files.
>>>>
>>>> I think it will be confusing and this recipe will fast grow.
>>>
>>> There are a few good reasons to do this.
>>>
>>> Machine customisation is spread around a whole load of different recipes
>>> at the moment and its hard to obtain a good view of what files are
>>> available and which ones a BSP author may need to provide.
>>>
>>> Its rather ugly to have to provide and maintain multiple bbappend files
>>> with rather ugly syntax within them. Its also rather inefficient from a
>>> build process standpoint to have 15-20 recipes just packaging
>>> configuration files.
>>>
>>> The intent isn't to mandate *every* config file should be in this
>>> recipe, you will as now be able to add additional ones. Where we see the
>>> same files being added in many layers, adding something common and
>>> shared makes sense though.
>>>
>>> It should in some cases also allow the "core" recipe to stop being
>>> machine specific and shared, improving build efficiency. There is little
>>> point in a recipe becomming machine specific over a config file.
>>>
>>> So I'd consider this move a consolation which we can improve over time.
>>> For new users I'd suggest that one more common place for the majority of
>>> machine specific files would be more understandable too.
>>
>> I understand and mostly agree. However I don't want to have a recipe
>> with 20 configuration files where I'd need just two.
>>
>> So I think we'd need to have a way to 'enable/disable' each
>> configuration override. Does it makes sense?
>
> I'd have thought our standard inheritance would apply so that if you
> didn't append a machine specific version, the default would be used?

That was my expectation as well.  We know a certain set of things -could-, and 
are commonly configured by a BSP.  So we have a configuration 'recipe' that can 
use either the default file (provided by the non-machine specific version), or 
the machine specific configuration as a replacement due to the package 
management system(s).

The inheritance mechanism should work that if you add a configuration it is 
enabled, otherwise it's not and the default version is used instead.  (That's 
what I thought the anonymous python is doing within the 1/10 patch.)

--Mark



> Cheers,
>
> Richard
>
>

Patch

diff --git a/meta/classes/conf-files.bbclass b/meta/classes/conf-files.bbclass
new file mode 100644
index 0000000..b937268
--- /dev/null
+++ b/meta/classes/conf-files.bbclass
@@ -0,0 +1,3 @@ 
+
+
+RRECOMMENDS_${PN} = "${PN}-conf"
diff --git a/meta/recipes-bsp/conf-files/conf-files_1.0.bb b/meta/recipes-bsp/conf-files/conf-files_1.0.bb
new file mode 100644
index 0000000..de7d893
--- /dev/null
+++ b/meta/recipes-bsp/conf-files/conf-files_1.0.bb
@@ -0,0 +1,84 @@ 
+SUMMARY = "Configuartion files master recipe"
+DESCRIPTION = "This package provides Configuration files for different packages that may need some kind of customization on a BSP level"
+
+LICENSE = "BSD || MIT || GPLv2"
+LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
+
+SRC_URI = ""
+S = "${WORKDIR}"
+
+
+CONF_PACKAGES = " \
+                 apmd \
+                 alsa-state \
+                 connman \
+                 formfactor \
+                 init-ifupdown \
+                 pointercal \
+                 xinput-calibrator \
+                 xorg-xf86-config \
+                "
+
+#                 bluze4 \
+#                 bluez5 \
+#                 keymaps \
+#                 tslib \
+#
+
+CONF_PACKAGES[apmd] = "${datadir}/apmd/apmd_proxy.conf"
+CONF_SUMMARY[apmd] = ""
+CONF_DESCRIPTION[apmd] = ""
+CONF_PACKAGES[alsa-state] = "${sysconfdir}/asound.conf"
+CONF_PACKAGES[bluez4] = "${sysconfdir}/dbus-1/system.d/bluetooth.conf"
+CONF_PACKAGES[bluez5] = "${sysconfdir}/dbus-1/system.d/bluetooth.conf"
+CONF_PACKAGES[connman] = "${localstatedir}/lib/connman/wired.config ${libdir}/connman/wired-setup"
+CONF_PACKAGES[formfactor] = "${sysconfdir}/formfactor/machconfig"
+CONF_PACKAGES[init-ifupdown] = "${sysconfdir}/network/interfaces"
+CONF_PACKAGES[pointercal] = "${sysconfdir}/pointercal"
+CONF_PACKAGES[tslib] = "${sysconfdir}/ts.conf"
+DEBIAN_NORENAME = "1"
+
+CONF_PACKAGES[xinput-calibrator] = "${sysconfdir}/pointercal.xinput"
+RCONFLICTS_xinput-calibrator = "pointercal.xinput"
+RPROVIDES_xinput-calibrator = "pointercal.xinput"
+RREPLACES_xinput-calibrator = "pointercal.xinput"
+
+CONF_PACKAGES[xorg-xf86-config] = "${sysconfdir}/X11/xorg.conf"
+CONF_PACKAGES_NOAPPEND[xorg-xf86-config] = "1"
+
+PACKAGES = ""
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+INHIBIT_DEFAULT_DEPS = "1"
+
+python __anonymous() {
+
+    do_install_cmd = ""
+    packages = (d.getVar('CONF_PACKAGES', True) or "").split()
+    for pn in packages:
+        if not d.getVarFlag('CONF_PACKAGES_NOAPPEND', pn):
+            pn_conf = pn + "-conf"
+        else:
+            pn_conf = pn
+
+        d.appendVar('PACKAGES', pn_conf + " ")
+        d.setVar('ALLOW_EMPTY_' + pn_conf, "1")
+        d.setVar('FILES_' + pn_conf, "")
+        d.setVar('CONFFILES_' + pn_conf, "")
+        conf_paths = (d.getVarFlag('CONF_PACKAGES', pn, True) or "").split()
+        print("conf_paths: %s" % (conf_paths))
+        for conf_path in conf_paths:
+            print("conf_path: %s" % (conf_path))
+            conf_dir = os.path.dirname(conf_path)
+            conf_file = os.path.basename(conf_path)
+            d.appendVar('SRC_URI', 'file://' + conf_file + " ")
+            d.appendVar('FILES_' + pn_conf, conf_path + " ")
+            d.appendVar('CONFFILES_' + pn_conf, conf_path + " ")
+
+            # Build do_install() fragment for each config file, only if it exists
+            do_install_cmd = do_install_cmd + "if test -s ${S}/" + conf_file + "; then\n"
+            do_install_cmd = do_install_cmd + "\tinstall -d ${D}" + conf_dir + "\n"
+            do_install_cmd = do_install_cmd + "\tinstall -m 0644 ${S}/" + conf_file + " ${D}" + conf_dir + "\n"
+            do_install_cmd = do_install_cmd + "fi\n"
+
+    d.setVar('do_install', do_install_cmd)
+}