On Wed, Jan 25, 2012 at 10:39 AM, Paul Eggleton <[email protected]> wrote: > On Wednesday 25 January 2012 09:49:14 Khem Raj wrote: >> meta-oe was started to fill in gaps that oe-core would have for >> existing oe users since oe-core will not have all required functionality >> and so distros could migrate to using oe-core and not loose the bells and >> whistles they already have. > > Sure, that's totally reasonable. I think we've built up some experience in the > time we've had so far that we can apply in order to improve the structure a > little though. > >> Plus its an umbrella layer which has many layers underneath. > > To save confusion, I speak only of the meta-oe layer within the meta- > openembedded repository. The meta-openembedded repository itself is not a > layer of any kind, only the directories within it are. (I really wish we had > chosen an entirely distinct name for the repository, but I guess that ship has > sailed.) > >> However the problems it sees right now are that there are pieces which >> could be considered distro specific and ones, the new untested recipes should >> not be an issue if they are pinned properly. > > So there ought not to be too much distro-specific in meta-oe; obviously there > is some at the moment due to the small number of distros actively using it. > > Unfortunately this pinning (I assume you mean PREFERRED_VERSION_) can only > really occur within a distro that already includes meta-oe, and then you need > to buy into the rest of the policy that that distro provides. If you are > starting only from OE-Core or your distro does not typically include meta-oe, > it will have no such pinning. >
oe-core does have policies see default* files under meta/conf however anyone who is using oe has to start with some policies iow distro if its a custom one or if its predefined one >> recipes that move our of oe-core I agree should be hosted in >> a meta-deprecated or somesuch >> >> I am happy to move out toolchain bits as well into a separate layer >> under meta-openembedded umbrella >> that will clarify it a bit and should not be a big hassle. > > Sounds great! toolchain is nothing but an example of conflicting recipes here. > >> I think real issue people suffer from is 2 and the duplicate recipes >> in meta-oe which has different configuration >> in oe-core. > > I agree these do need to be well-justified, and should avoid being just > manifestations of distro policy. These are gradually being ironed out where > appropriate, we just need to continue with this process. yes this area needs some attention and I would request everyone to clean this bit. > >> So meta-oe meta-toolchain meta-deprecated could be created now we need >> to find maintainer for these layers. > > It might be a bit presumptuous but I would nominate you for the toolchain > layer ;) since you more or less maintain the recipes that would go in it > already. (I guess meta-toolchain probably isn't the best name since that > already means something in OE.) > I think right now eglibc 2.12 is one of deprecated recipes that moved into meta-oe and I know angstrom currently depends on it. Sometimes if there are no more than one layer who depends on a deprecared recipe it might be better to move it to that layer itself. so some careful decision would be involved when moving them around. meta-deprecated may sound like deprecated but it should actually be a maintained layer. > As for the other layers I would be happy to assist Koen in maintaining them if > he would like, but I think he's been doing a fine job with meta-oe already. > >> All said if it was possible to handpick versions from layers and use >> bitbake -g output pn-depends.dot >> to generate some manifest so indicate which recipe is being picked >> from a set of recipes from different layers would be helpful. >> since there always will be some duplicate recipes no matter what. > > The bitbake-layers tool is supposed to help at least with the reporting side > of this, and it does report where bbappends exist and recipes have been > overlayed. Right now however it does not report anything if a recipe is > overlayed but the version number is different; I'm looking into fixing that at > the moment. BTW I'd appreciate feedback on bitbake-layers as I've not had a > lot since it was extended - feature requests welcome. > hmm I have not used it but I will try. Its I think very important that user knows which recipe it feeding into the build. Especially when there are multiple recipes in the layers he/she is using. Second thing would be .bbappends as to how the recipe was bbappended. > As an aside, we also still have to consider Richard's proposal for version- > independent bbappends (i.e. using % as a wildcard in the file name). I don't > think anyone responded to that yet. > We should discuss that in separate thread. > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
