Re: Patch.bbclass URL Reasoning

Re: Patch.bbclass URL Reasoning

[Robert Abel]

Bumpity...

So nobody is aware of this issue or has ever tried to edit a patch
before do_patch?

Regards

Robert

Re: Patch.bbclass URL Reasoning

[Paul Eggleton]

On Tuesday 27 March 2012 14:41:35 Robert Abel wrote:
> Bumpity...
> 
> So nobody is aware of this issue or has ever tried to edit a patch
> before do_patch?

I'm aware of the behaviour, I can't speak to its intention (well, the part 
where it symlinks back to the original patch I suspect intended to allow you 
to update the patch in the metadata, but I don't know why we also copy the 
patch to the WORKDIR as well). 

However if I needed to do what you want to do I would do it differently - 
instead of modifying the patches, why not just modify the file(s) in the source 
code directly? I would suggest using sed in a do_configure_prepend() to change 
the values in the source to the desired value from a variable. Depending on 
the complexity you could have the patches change the values to some easily 
replaceable string beforehand.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patch.bbclass URL Reasoning

[Paul Eggleton]

On Tuesday 27 March 2012 14:58:23 Robert Abel wrote:
> On 27.03.2012 14:55, Paul Eggleton wrote:
> > However if I needed to do what you want to do I would do it differently -
> > instead of modifying the patches, why not just modify the file(s) in the
> > source code directly? I would suggest using sed in a
> > do_configure_prepend() to change the values in the source to the desired
> > value from a variable. Depending on the complexity you could have the
> > patches change the values to some easily replaceable string beforehand.
> 
> That's exactly what I'm doing right now. However, since I'm patching the
> kernel and users could theoretically add patches containing my magic
> strings, I wanted to avoid a sed on git\* and instead only edit *.patch
> in ${WORKDIR}, which is why I'm asking why the copied patches go unused.

Well, I can't answer that, but I don't think it's too difficult to come up with 
a string that's unlikely to ever occur in the kernel sources.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patch.bbclass URL Reasoning

[Bruce Ashfield]

On Tue, Mar 27, 2012 at 9:05 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Tuesday 27 March 2012 14:58:23 Robert Abel wrote:
>> On 27.03.2012 14:55, Paul Eggleton wrote:
>> > However if I needed to do what you want to do I would do it differently -
>> > instead of modifying the patches, why not just modify the file(s) in the
>> > source code directly? I would suggest using sed in a
>> > do_configure_prepend() to change the values in the source to the desired
>> > value from a variable. Depending on the complexity you could have the
>> > patches change the values to some easily replaceable string beforehand.
>>
>> That's exactly what I'm doing right now. However, since I'm patching the
>> kernel and users could theoretically add patches containing my magic
>> strings, I wanted to avoid a sed on git\* and instead only edit *.patch
>> in ${WORKDIR}, which is why I'm asking why the copied patches go unused.
>
> Well, I can't answer that, but I don't think it's too difficult to come up with
> a string that's unlikely to ever occur in the kernel sources.

Or perhaps come up with a different model all together that avoids the need
to modify the patches on the fly :) I've had to do things very similar to this
before, and I've solved it with the include of a generated file.

That being said, I am painfully aware of the different patch locations and what
does or doesn't get used, since I had to adapt the feature processing of
linux yocto to figure out the WORKDIR variant (so there would be somewhere
writable).

That being said, the current behaviour has advantages that via the
absolute / source location of the patch, it's possible to examine the entire
directory without having to modify bitbake to recognize the files and do the
copy to WORKDIR.  Summary: the current behaviour works, and if it changed,
existing semantics would break, so if it was changed the return of WORKDIR
versus source location would be better done as an option.

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Patch.bbclass URL Reasoning

[Robert Abel]

Hi,

Could somebody enlighten me why the following is done in patch.bbclass?

> def src_patches(d, all = False ):
>     workdir = d.getVar('WORKDIR', True)
>     fetch = bb.fetch2.Fetch([], d)
>     patches = []
>     sources = []
>     for url in fetch.urls:
>         local = patch_path(url, fetch, workdir)
>         if not local:
>             if all:
>                 local = fetch.localpath(url)
>                 sources.append(local)
>             continue

As you can see (or guess), patches are resolved back to their original
URLs inside the recipe folder. The ones that are copied to ${WORKDIR}
during unpack don't seem to be used at all. Is there any special reason
why this is done?

Basically, I was happily editing patches using sed when I noticed that
my changes weren't applied at all. I thought the patches are copied to
${WORKDIR} precisely for the reason that they are used, i.e. can be
edited before patching.

The reason for editing them in the first place is that they contain
specific IDs (which I put there) that a task before do_patch replaces
for actual values (e.g. MHz for external hardware) for the board
configuration so my users will be able to simply change a variable
inside their local.conf for added comfort/ease-of-use.

It seems the patches are copied just because and aren't actually
utilized at all. Could this behavior be changed to use the copied
patches instead of the original patches inside the recipe folder? IMHO
it would make much more sense to be able to edit the patches before they
are being applied without having to overwrite the original patches in
the process.

Regards

Robert