| Summary: | offer a way to use sstate-object hashes as dependencies of builds/packages | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Gustavo Sverzut Barbieri <barbieri> |
| Component: | bitbake | Assignee: | Unassigned <unassigned> |
| Status: | RESOLVED OBSOLETE | QA Contact: | Apoorv <apoorv.sangal> |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | alexandru.c.georgescu, jose.perez.carranza, joshuagloe, poky.bs.watcher, poky.watcher, randy.macleod, richard.purdie |
| Version: | 5.99 | ||
| Target Milestone: | Future | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Gustavo Sverzut Barbieri
2015-11-18 00:43:13 UTC
We have a possible solution for this issue already, perhaps it's sufficient? We can generate a locked-sigs include file with: bitbake my-image-name -S none which produces locked-sigs.inc in the build directory. If you then include that file, say in local.conf: include ../locked-sigs.inc Future builds where the sstate signature of a package has changed will result in an error. A snipped example from a test here: The util-linux:do_build sig (4847af183e8a78714aee4d3d3e1813c0) changed, use locked sig 14e39f1ab2f95fad5cdfacaa8d4ea6e1 to instead The libpam:do_build sig (caf45d5c74b4709c05de993756fb94cb) changed, use locked sig a9254c62e6fa42809c349ce9f7a7ba3f to instead The kbd:do_build sig (681a3d1fc829482a371c39bd62b2aa2f) changed, use locked sig 3bcb74e6b5962cb1511d59cc35c8c09f to instead The e2fsprogs:do_packagedata sig (7e5195dbf24226853edebfc80d098ee4) changed, use locked sig ae2103a61fd293c172da6282030d02cd to instead The libcgroup:do_build sig (d3e0c508f0a445fa26645854544c21bf) changed, use locked sig 22e166edb793e1bd27f0f8a052e81b26 to instead The dbus:do_build sig (9f4a2c65cbd47bb010cd0334b94b136b) changed, use locked sig a9d13838c176c7084490237cfca15242 to instead The e2fsprogs:do_build sig (96bd6fddcc93694d4e8c27e0bff28d35) changed, use locked sig d72cda97410bc402caa25d00c0f289f8 to instead The systemd:do_build sig (d9898b810c9f0ea22a2835d9ba7a1f29) changed, use locked sig a8feaceacbdefb49757fad6646181193 to instead Additiaonlly, we can change the error (which prevents a build) to a warning with: SIGGEN_LOCKEDSIGS_CHECK_LEVEL="warn" I believe this provides a solution to the request to emit the sstate hashes (the locked-sigs include) and also demonstrates extra mechanisms we have already built around that. At the very least we need to make some documentation updates to better demonstrate this functionality. looks like that is the building block, but we'd need to work on the user experience, not just document that.
For instance always generate the locked-sigs.inc, list just the packages that fail the signatures (not the actual signature), ask for confirmation and if confirmed then it would update locked-sigs.inc automatically and proceed. Something like:
$ bitbake myimage-with-changes
The following packages will be rebuilt:
util-linux
libpam
kbd
Do you want to continue [n/Y]?
Ideally we if we could pin-point why it happened, we could use a "--verbose" switch to produce something like:
$ bitbake myimage-with-changes --verbose
The following packages will be rebuilt:
util-linux (CFLAGS: added -Wl,--gc-sections)
libpam (PACKAGECONFIG: added xpto)
kbd (changed dependency libXPTO)
Do you want to continue [n/Y]?
Answering "Y" or a "--no-confirm" switch would proceed with build and would update the lock-sigs.
it seems this is related to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6428 Resetting assignee, importance and status so that this can be reassessed by the triage team. isn't this reusable sstate? we are in the middle of finishing this up are we not? Implementation of bblock/bblunlock tool is prefered. A defect for that exists. |