On 5/27/14, 3:39 PM, Darren Hart wrote:
On 5/27/14, 11:35, "Saul Wold" <[email protected]> wrote:
Folks,
We have had an open enhancement in the form of bugzilla #4011
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011).
I am currently working on this and want to get some feedback regarding
the design, the below list of config files would move to one recipe in
recipes-bsp, which will reduce the number of .bbappends that a BSP
writer might need to create in order to customize the configuration of
the BSP.
Overall, my proposal is to move all the BSP related config files into
one recipe directory tree. Create a recipe that can have a package or
packages that are RRECOMMENDS on.
We have 2 choices on the packaging side:
1) 1 Package to rule them all (conffiles)
- RPROVIDES PN-conf
- conffile.bbclass
RRECOMMENDS = "${PN}-conf"
# Can be overriden in recipe
CONFFILES_conffiles ?= "${PN}.conf"
- Will provide files not needed on final image, small
amount of extra space used.
2) 1 package / conf file (${PN}-conf)
- exactly what's needed will be installed
- no needs for additional RPROVIDES
- More packaging overhead, package data might be bigger than actual
contents!
The status quo would suggest that Option 2 is more consistent with what
people expect of the build system. However, if we were to do this, one
might question why we should bother at all and not just leave it in the
hands of MACHINE-specific overrides for the packages we're configuring, as
is done today with alsa-state/asound.conf (for example).
What was your idea here - to replace the MACHINE-specific config for these
packages - or to augment it with an optional mega-config package?
The reason to get away from MACHINE-specific config changes to the regular
package is from a re-use standpoint.
If BSP_A and BSP_B both need different configurations of the FOO recipe, the
"right" way today is for two machine specific versions of the FOO recipe/package
to be generated.
foo-ver-rel.BSP_A.rpm
foo-ver-rel.BSP_B.rpm
This eliminates a lot of potential re-use, and if it's a large package could add
a lot of unnecessary space (and build time) to the system.
Instead what we want is:
foo-ver-rel.armv7.rpm
foo-conf-ver-rel.armv7.rpm
foo-conf-ver-rel.BSP_A.rpm
foo-conf-ver-rel.BSP_B.rpm
So the package management system will select the best package to meet the
requirement automatically. You get to re-use the one foo package on all
compatible system. And then you can choose from a default (not-configured), or
a BSP configuration. Much quicker to package, install and takes (potentially)
less space. (On a trivial hello-world example, it'll actually take more space,
but get outside the trivial and it will be helpful.)
I think it would help to provide a bit of background/motivation regarding
what exactly we're trying to accomplish with this. That would help me form
an opinion on 1 vs 2 anyway.
So when talking with Saul I suggested that we do either #1 or #2.. and the base
recipe (not configure) had a require or recommend of the configure file.
The more I think about this, the more I think multiple small configuration
files/packages makes sense.. due to various system configuration possibilities
-- but using appropriate RPROVIDES we shouldn't prevent the system from allowing
a single monolitic configuration for a BSP.
--Mark
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
