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? > 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
