static IDs bugs and usability
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 patch 0 repliesNew
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/1 | useradd-staticids.bbclass: trigger reparsing when table files changemeta/ | +13 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/1] static IDs bugs and usability
In Ostro OS we just started to use useradd-staticids.bbclass. Dynamic IDs are an error (USERADD_ERROR_DYNAMIC = "error") by default because warnings probably wouldn't be noticed. I was a bit reluctant to make this change because Ostro OS is supposed to be customizable, and that becomes harder when developers also have to define IDs.
But we didn't have a choice because after updating to recent OE-core, our dynamically assigned IDs started to change randomly between builds, which (as we learned only because of that change) broke the swupd update mechanism. Personally I suspect that Python3's randomization feature is responsible for not getting deterministic results anymore, but I haven't investigated further.
useradd-staticids.bbclass has a bug which impacts developers when they edit the table files to fix a warning or error raised by the class:
the cached version of the affected recipe continues to be used and thus editing the files has no effect. Patch fixing that follows.
There's also a caveat associated with how USERADD_ERROR_DYNAMIC = "error" is implemented: it marks recipes as "skipped" with an error messages from useradd-staticids.bbclass. This is not particularly developer-friendly.
For example, when the skipped recipe is deep down in the dependency chain, then building will fail with rather difficult to understand "nothing provides..." messages. It does mention eventually that a recipe was skipped with the right error, so the information is at least there.
However, it's also possible that a recipe exists in two versions, and only the one normally picked as default gets skipped. In that case, the remaining version will get build, i.e. useradd-staticids.bbclass has the very undesirable effect of silently building something else than expected instead of aborting the build because of the error.
I've not seen that in practice, though, so I don't know how big of a problem it is.
The following changes since commit b32d430c3c7dccf3a8d06ab492d648893a05950f:
dpkg: use snapshot.debian.org for SRC_URI (2016-07-26 08:56:08 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-core static-ids
https://github.com/pohly/openembedded-core/tree/static-ids
Patrick Ohly (1):
useradd-staticids.bbclass: trigger reparsing when table files change
meta/classes/useradd-staticids.bbclass | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Signature · 1 line
2.1.4