> I agree the patch has a use in its own right, standalone. I am however > asking us all to take a step back and consider the big picture which is > what I need do with a lot of what we're doing. > > My point is that whilst in isolation its ok, I don't think that approach > can scale to fulfil all the varying needs of our users. If it can't, we > need to look at what can, and then how we could include equivalent > functionality.
Okay. > Even with the code we're discussing, you need an external tool to create > the list and to update it at appropriate points from upstream so you > really might as well have that code actually do the fetch as well > (calling bitbake's fetchers)? Well in its current state, you don't need one, but it makes it a lot easier. OTOH all this discussion more or less centers around BBLAYERS which is already easy to use. > I'm much more worried about the workflow and its implications than I am > about the actual code. Okay. More ore less this really only expands the options for workflow. > I think layers are a bit different to a lot of the source code we > currently fetch. We might want to push things back, transfer commits > between layers and perform a number of other operations. Unless we are writing a new set of fetchers(internal or otherwise), the limitation is the fetchers, since they don't do this. > These > operations all require "state" type data that currently we can't store > in a SRC_URI. I'm not even sure we want to store it there. Wouldn't you have the same issue with a git repo tracking recipe? > > There has been discussion about this in person at Collab/ELC and on > the mailing lists/wikis but we probably need to do better at > communicating this I guess :/ Yes. Been following a long, trying to contribute where it made sense. OTOH, in the end, if it is insufficient for our needs we can't use it. > The whole point of Yocto is to collaborate. I'm pleased to have your > input in the form of the patches and I really do appreciate that. > > This doesn't however guarantee we take them "as is" since we've also > consulted with a number of other people about what their needs are and > your solution whilst evidently perfect for you doesn't meet all the > criteria we established during the planning process. I never suggested that anything be taken as is. In the irc discussions with Paul, we talked about the bits that we wanted to change. > We're trying to > write some tools that should work for everyone. It may require some > changes in process for some people, hopefully these will be logical and > improve the user experience and understanding. Understood, otherwise I wouldn't be having this e-mail exchange with you at all. > There are a variety of ways I think we could even directly make your use > case work (such as bitbake automatically calling the external update > tool if some environment variable is set). Okay. > Collaboration means there are > more than just your requirements that need to be worked into this at > this point. Nor have I suggested that you guys were. > What's the opinion of fetch2 at this point? I'm hoping we can rely on > that for all future development work at this point. >From the I am just using fetchers in a more or less rudimentary manner, it feels more or less the same(which kind a was the point). I have not really used any of the additional stuff that has been added in, but more powerful and functionally rich code is always a positive thing. Also I am currently supporting fetch with our older product so when I wrote the patch, making it work with fetch seemed a good idea. > > I'm probably confusing this with the first version you sent out I guess, > sorry. > That was my point, there was only one. Really doesn't matter. >> We can move the setting of that stuff to the init of the fetchers, and >> that wouldn't be a big deal. > > I understand that. You're not thinking about what I'm suggesting ;-) > I caught what you were striving for there. -- Jeremy Puhlman Montavista Sofware, LLC. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
