On Tue, Oct 2, 2012 at 11:45 AM, Jerrod Peach <pea...@lexmark.com> wrote: > Tomas, > >> >> Sounds to me like your situation implies a single distro + multiple >> machines, one for each distinct printer model; you can then specify >> revisions on per-machine basis. > > > I don't think that's actually what we want. The architecture of each > machine will be the same. That is, one ASIC will generally be on all the > printers in a family of products. I think I actually have one machine + > multiple distros. Or, should I really be counting each different printer as > its own machine?
well if machine is same then it should be so. But you can have different images meant for same image. e.g. image-printer1 image-printer2 etc. however this may not be best if you want two different versions of same package X in those two images. You could also look into package groups and IMAGE_FEATURES. I think if you need to put two different revs of same package then branching may be better approach or you could have multiple recipes X-printerA.bb X-printerB.bb and so on and chose the right one into image-printerA and so on. There are many ways you can use. You have to look into what fits best to your needs > >> >> Whether you specify the machine specific >> revisions in the bb files, or whether you pull it together into an >> include file is a matter of taste more than anything else I suspect, as >> long as everyone knows what the deal is. But I'd advise not to specify >> package revisions local.conf, that's really for the developer/user to >> tweak, and it should not be stored in vcs, doings so just causes pain. > > > That's something that's come up in our side conversations here: local.conf > is really for developers to tweak. I will try to take care and not use > local.conf for such a thing, and I will not store it in a VCS unless I can > think of a really compelling reason to do so. Thanks for the advice there. > >> >> >> I use the unified include file in Guacamayo for the packages that we >> maintain; this is for convenience, as during the development cycle I use >> AUTOREV for these packages, but for an actual release specify the >> revisions explicitly and having them all in one place makes this easier >> to do and not forget anything. See, >> >> https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/conf/ >> for how we got it set up. > > > So, to me it looks like you're using conf/distro/guacamayo.conf to set those > revisions. That seems like that might work when there's only a handful of > revisions to set. However, we'll likely have at least a hundred packages > for which we need to set/manipulate revisions. I would think that would get > cumbersome, and in an organization the size of ours (500 or so developers > across two sites), there's not really going to be one person or team who > knows what should go in that file for a release. Moreover, that still > leaves the problem of all those developers needing to know there are at > least two places in which their package revisions may be controlled. Is > your organization significantly smaller than that or are we doing something > wrong? > > Kind regards, > > Jerrod > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto