On Thu, Nov 5, 2015 at 9:05 AM, Paul Eggleton <paul.eggle...@linux.intel.com> wrote: > On Thursday 05 November 2015 11:25:18 Chris Hallinan wrote: >> On Thu, Nov 5, 2015 at 4:25 AM, Paul Eggleton >> >> <paul.eggle...@linux.intel.com> wrote: >> > On Wednesday 04 November 2015 17:16:32 Khem Raj wrote: >> >> > On Nov 4, 2015, at 11:57 AM, Chris Hallinan <challi...@gmail.com> >> >> > wrote: >> >> > I was trying to "patch a patch" in a u-boot recipe using standard >> >> > bbappends technique. I added a task before do_patch after do_unpack >> >> > to munge the patch that was broken. Here is what seems to happen: >> >> > >> >> > do_unpack: >> >> > copies all the patch files from the metadata layer into ${WORKDIR} >> >> > >> >> > do_fix_patch (my additional task) >> >> > >> >> > uses sed or patch to apply a local fix to a broken patch in >> >> > ${WORKDIR} >> >> > >> >> > do_patch >> >> > >> >> > creates a subdirectory in ${S} called "patches", and puts links to >> >> > >> >> > the actual files in the layer and uses those links back to the layer >> >> > files to apply the patches. >> >> > >> >> > It seems quilt is using the actual layer files instead of the ones in >> >> > ${WORKDIR}?? >> >> > >> >> > This seems odd and somehow wrong. We copy the layer files into >> >> > WORKDIR, and the unsuspecting user (me) thinks those are the files >> >> > that do_patch will use. >> >> > >> >> > This one took me some time (and help) to figure out! >> >> > >> >> > Comments? Is this a bug? halfway in the middle of some architectural >> >> > changes? Expected behavior? >> >> >> >> while what you are doing is quite questionable. You seem to have a point. >> >> Most probably copy of the files in workdir should be removed from >> >> happening. >> >> >> >> > My workaround was to simply replace the entire patch. >> >> >> >> you should use the quilt workflow and edit/refresh the patch once and >> >> copy >> >> it back to metadata once for all yes. >> > >> > Or devtool modify, change the patch in the resulting git repository, then >> > devtool update-recipe -a. >> >> Thanks for comments. But the point here is that in some workflows >> (especially with a commercial vendor's implementation) we strongly >> encourage users _NOT_ to modify the distributed sources, but to make >> all modifications in users layers. This provides a more manageable >> upgrade path. I guess the strangeness is that files from >> recipe/metadata are copied to WORKDIR, but are not used, and I found >> that very confusing at first. Lesson learned! ;) > > Right, that's what the -a does though - puts your change into a bbappend as > opposed to the original recipe. > >> I guess I find it a bit strange that quilt (I assume it's quilt) links >> back to the layer/metadata files directly and not back to the files in >> WORKDIR, which seems more reasonable and easier to modify. I could >> label this as a "bug" rather than a "feature". Matter of perspective, >> perhaps. > > Yeah, I think it would be reasonable to fix this as well. I have sometimes > wondered myself why the symlinking was done this way.
its time/space optimization more than anything you avoid copying and copies > > Going forward though I would like to encourage people to use devtool modify > for this kind of thing rather than working with files in the WORKDIR, because > among other things there's less chance of losing work when WORKDIR goes away. > If that means we need to enhance or fix devtool so it works better for people > then by all means let's do that. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto