On 4/20/17 7:37 AM, Alexander Kanavin wrote: > On 04/19/2017 04:03 PM, David Vincent wrote: >> The problem is that I must be able to manage the configuration of a machine >> without physical intervention and only via package upgrades. A new >> configuration can be applied simply by incrementing the PR of a configuration >> package. >> >> But maybe this is a use case only needed by me and I should manage it in my >> own specific layer ? >> >> Now that I think of it, I have the same kind of problem for all machine >> specific configurations. For now, I just replace the PACKAGE_ARCH in my BSP >> layer with a machine specific one to indicate that a package contains a >> configuration valid only for a specific machine. Maybe, in a future release, >> it >> should be desirable to create -conf packages based on the CONFFILES variable >> ? >> I don't know if it's a good idea, but maybe I could bring that up on the >> architecture mailing list ? > > By all means please do so. Yocto lacks a solution for configuration > management, and this was discussed some time ago, although I cannot > anymore find where it happened. Mark, do you remember? >
I don't remember anything specific about the configuration management, just that we discussed it. Sorry. I do know that this is an issue, and what we've said in the past was create a .bbappend, set PACKAGE_ARCH to MACHINE_ARCH, add your machine specific configuration to the package. Down side of this is that if only the configuration file is different then you now have a separate binary specific to that machine -- wasted space on a feed server. The other alternative I know of is to use the rootfs post scripting and replace the conf files with the ones specific to that -build-. This is similar to a manufacturing step in a traditional ODM/OEM relationship. At least with RPM, if the CONFFILES are set right, any configurations set this way should NOT be overridden on a target upgrade. (and any CONFFILE entries not set right are bugs IMHO...) --Mark > Alex > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
