[yocto] suggestions for version controlling multi-layer reproducible builds?
Christopher Larson
clarson at kergoth.com
Mon Dec 12 07:25:45 PST 2016
On Mon, Dec 12, 2016 at 8:20 AM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:
> if one is building an image for a releasable, commercial product,
> and that image involves pulling in numerous layers, then dumping all
> sorts of proprietary apps on top of it, what are the possibilities for
> how to version number the released images such that, if a client has
> an issue, they can identify precisely the state of components that
> went into the system they're working with?
>
> in addition to all of the layers involved in the build, one has to
> take into account that, when critical bugs are identified, an updated
> RPM might be sent out and applied, whereupon that system's version
> number is no longer perfectly accurate. in the end, the state of
> someone's running system will be determined by a possibly huge
> combination of selected packages, preferred package versions, build
> config options, additional user space apps, hot fixes that have been
> applied and so on.
>
> what sort of meaningful "version number" can be applied to something
> like that? i'm sure at least a few other people have to be doing
> something like that, so i'm open to suggestions.
>
I don’t think it’s possible for a version number to capture this at all.
Better to use a script to capture the state of the system as needed. I.e.
write build info to a file on target, and then combine that with a query of
the package manager if you use packages for update distribution (though I
wouldn’t advise use of packages for update distribution at all, that’s a
different discussion :).
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20161212/3c9fe020/attachment.html>
More information about the yocto
mailing list