On Tue, Oct 02, 2012 at 12:43:27PM -0400, Jerrod Peach wrote: > All, > > After spending a few years working with a several-years old forked and > heavily-modified version of BitBake, my company is looking at switching to > using Yocto to build embedded Linux for its printers. I've been playing > with/writing tools and process around Yocto for a couple of months now, and > I'm getting to the point where I can produce integration builds without a > problem. > > Now I'm starting to think about how our release process should work with > pure Yocto and I'm running into a conundrum. Before I get into that, > though, let me very briefly explain how we release code currently in terms > of Yocto as it is today. This is not exactly what we do, but if I had to > explain the real process, it would take a while because of all the > customization we bolted on top of our forked BitBake. Basically, we have a > branch in a repository containing the equivalent of local.conf, and we put > fixed revisions of every package for that release into the local.conf file > within that branch. As patches for a release come in, the local.conf file > is updated to point to the new patches. > > I was thinking about doing something very close to that in actual Yocto, > except I'd store only the revisions/branches that were different from what > the bb file prescribed in local.conf. I ran that idea by a couple of > colleagues separately and they both immediately pointed out a concern: they > didn't want to have two different places that could manage the revision of > the package, i.e. local.conf and the package bb file. They don't like how > that works in the system we have today. Instead, they wanted to branch all > the metadata and have people update individual bb files with different > revisions as necessary. That leaves only one place to manage the revision: > the package bb file. Doing all that branching concerns me (it seems > heavier-weight than it needs to be, at the very least), but I can't say > specifically why branching the bb files is harmful. If you guys can think > of a reason why, let me know. If you think it's reasonable, let me know > that too.
I think that branching (or tagging) whole metadata is best option, use AUTOREV from some .inc file (included in local.conf) for development and then just before release update in recipe SRCREVs with small script from bitbake persistent cache (tmp-eglibc/cache/bb_persist_data.sqlite3). This way you will get correct SRCREVs in branched metadata and won't need so many recipe updates during development to move SRCREV too often. Cheers, > I'm also starting to think there might be a better way to handle this with > Yocto's concept of distros (perhaps have a distro for printer X, and a > different one for printer Y, each pointing at versions of code that are > good for the respective printer), but my research so far hasn't given me > enough information on distros to know if this is a reasonable approach. > (I've poked through some of the documentation and the mailing list > archives.) So, what do you all do for releasing code? Does anyone have a > situation similar to mine? (I can't imagine I'm unique, but maybe I'm more > special than I thought.) Even if you don't have a situation like mine, > what would you suggest I do for releasing code for our printers? > > Kind regards, > > Jerrod > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
