-----Original Message-----
From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Robert P. J. Day
Sent: Monday, December 12, 2016 10:20 AM
To: Yocto discussion list <yocto@...>
Subject: [yocto] suggestions for version controlling multi-layer reproducible
builds?


(if there's already a doc section for this somewhere, a pointer to it would be
just ducky.)

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?

For my setup I have a separate package that is the distribution version number. Whenever we release an update, the distribution version number is updated. We then tag all our layers with the distribution version number for proper record keeping. The Angstrom distribution was (or maybe still is?) doing something similar and was the inspiration for our setup.

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.

rday

Any time we release an update, no matter how minor, we update the distribution version package. Otherwise, as you state, you could have an update that you can't reproduce. We also archive the package repository and generated image files for each release so we can flash a board with a previous release and test from there. It can be a pain to get the process down the first time, but after that a simple Bash script can take care of all the hard work for you and ensure you don't skip a step.

Bryan

--

==========================================================
==============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
==========================================================
==============


--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto