This seems to assume that every project is similar and that develop vs
production is something well defined. Well, it's not.
I for one would welcome the demise of debug-tweaks. It's an option that
enforces one of two policies that may both be wrong.
For example, if the target is a settop box where users tend to port-forward
the SSH port to the internet, and which is open so that they're expected to
log in and make changes, the policy we want is that there is initially no root
password, and that SSH access requires a valid password. This makes the system
secure against outside attacks. Setting debug-tweaks will allow blank SSH
passwords, while not setting it would invalidate the root login. Neither is
acceptable for this project, so one has to resort to overriding the image
class methods zap_root_password and ssh_allow_empty_password to do nothing.
Instead of some obscure switch with implications hidden somewhere in various
recipes, classes, distros and local configs, can't we just define options that
actually do what they say, like for example a boolean option
"ssh_allow_empty_password"?
While the "development/production" switch may be great for some projects,
it'll make things only more complicated for others while gaining nothing above
what we have now.
On 15-05-17 15:26, Patrick Ohly wrote:
At OEDAM [1] I took the AR to flesh out some of my ideas for
introducing global and per-image settings for switching between
development and production builds. The goal is partly to establish
common configure options that then can be used by different layers,
partly to have some actual useful functionality attached to them
already in OE-core.
"development" builds are what a developer does when trying out a
distro or working on his own personal device. "production" is what
device manufacturer put onto the actual end-user hardware.
At OEDAM we already concluded that per-image settings are more
useful. However, sometimes a component also has compile-time choices
that cannot be changed later on in an image, and indeed I found one
example for that (kmod) in OE-core.
Therefore I have included "debug-build" DISTRO_FEATURES support. It's a
bit similar to manpages.bbclass, but in contrast to that (currently)
is meant to be inherited globally - that's partly due to
misunderstanding how manpages.bbclass was meant to be used. This can
be changed, for now I just want to demonstrate that such a distro
feature is not entirely useless, and what effect it could have already
in OE-core.
In refkit, we also switch globally between development and production
builds via .inc files. However, I am in the process of replacing that
with the more flexible per-image IMAGE_MODE check. So from my
perspective, the IMAGE_MODE is more important and useful than the
"debug-build" DISTRO_FEATURE.
From a design perspective, the approach taken here is to let a
developer or image define what mode it wants, and default features can
be configured accordingly. That alternative would be to continue defining
features as before and use the mode to configure QA warnings or errors.
But I find that less flexible, and I suspect it would be harder to
keep track of what is meant to be usable in which mode. Developers
also would have a harder time overriding the defaults.
[1] https://www.openembedded.org/wiki/OEDAM_2017
Patrick Ohly (6):
build-mode.bbclass: distro-wide debug-build mode
basefiles: warn about non-production DISTRO_FEATURES in motd
defaultsetup.conf: enable special "debug-build" DISTRO_FEATURES support
image-mode.bbclass: per-image production/development/debug mode
image.bbclass: include IMAGE_MODE support
local.conf.sample: make debug-tweaks depend on IMAGE_MODE
meta/classes/build-mode.bbclass | 16 ++++-
meta/classes/image-mode.bbclass | 62 ++++++++++++++++-
meta/classes/image.bbclass | 3 +-
meta/conf/distro/defaultsetup.conf | 2 +-
meta/conf/local.conf.sample | 5 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 11 +++-
6 files changed, 96 insertions(+), 3 deletions(-)
create mode 100644 meta/classes/build-mode.bbclass
create mode 100644 meta/classes/image-mode.bbclass
base-commit: 9f9ebf2e1ba6eda48fb5e3f20d4ca5bbabe3dad4
Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st
June 10 AM
Visit http://eabeurs.nl/author/612884/ for more information
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
