[RFC] patch file location

[RFC] patch file location

[Frans Meulenbroeks]

I'd like to draw the attention to the location of patch files.
My original understanding was that these should be in either the files
dir (if they apply to all), or in a dir with the name of the recipe
(replacing the _ with a - ).
And I kind-a assumed that if a patch is in a recipe dir it would have
priority above a version in the files dir.

However, this does not seem to be enforced.
I noticed some packages do also not live up to this.
One example is glibc.
Take one patch as example: arm-memcpy.patch:

This patch occurs in 5 dirs:

recipes/glibc$ ls -l */arm-memcpy*
-rw-r--r-- 1 frans frans 17071 2010-06-02 15:57 glibc-2.2.5/arm-memcpy.patch
-rw-r--r-- 1 frans frans 16957 2010-06-02 15:57 glibc-2.3.2/arm-memcpy.patch
-rw-r--r-- 1 frans frans 16960 2010-06-02 15:57 glibc-2.4/arm-memcpy.patch
-rw-r--r-- 1 frans frans 16993 2010-06-02 15:57 glibc-cvs-2.3.5/arm-memcpy.patch
-rw-r--r-- 1 frans frans 16960 2010-06-02 15:57 glibc-cvs/arm-memcpy.patch

Looking at the size these are at least 4 different versions

This patch is referenced in 14 recipes:

recipes/glibc$ grep arm-memcpy *
glibc_2.10.1.bb:           file://arm-memcpy.patch \
glibc_2.2.5.bb:	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.2.bb: 	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.2+cvs20040726.bb:	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.3+cvs20041128.bb:	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.3+cvs20050221.bb:	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.3+cvs20050420.bb:	   file://arm-memcpy.patch;striplevel=0 \
glibc_2.3.5+cvs20050627.bb:	   file://arm-memcpy.patch \
glibc_2.4.bb:           file://arm-memcpy.patch \
glibc_2.5.bb:  file://arm-memcpy.patch \
glibc_2.6.1.bb:  file://arm-memcpy.patch \
glibc_2.7.bb:           file://arm-memcpy.patch \
glibc_2.9.bb:           file://arm-memcpy.patch \
glibc_cvs.bb:#	   file://arm-memcpy.patch;striplevel=0 \
glibc_cvs.bb:	   file://arm-memcpy.patch \

Frankly speaking I have no clue at all which version of the patch will
be used by the 2.10.1 recipe. The only ways to find out is to study
the class code that does the patch or to actually build the package
(in the hope it selects the patch in a deterministic way). I don't
think it is good that if someone is debugging a problem that they
should have such a hard time to find out what version of a file is
actually used

My proposal:
- only apply patches (seek for patches) in the recipe dir (e.g. in the
example for glibc_2.10.1.bb this would be glibc-2.10.1) and in the
files directory

(optionally we might allow for a mechanism that allows specifying
patches for higher level recipes; e.g. glibc_2.10.1 could look in
glibc-2.10.1, glibc-2.10, glibc-2, glibc and files).

How do people feel about this? Any implementation hints?

Frans

Re: [RFC] patch file location

[Marcin Juszkiewicz]

Dnia wtorek, 22 czerwca 2010 o 09:03:43 Frans Meulenbroeks napisał(a):
> I'd like to draw the attention to the location of patch files.
> My original understanding was that these should be in either the files
> dir (if they apply to all), or in a dir with the name of the recipe
> (replacing the _ with a - ).
>
> And I kind-a assumed that if a patch is in a recipe dir it would have
> priority above a version in the files dir.

This is controlled by FILESPATHPKG and OVERRIDES.

> Frankly speaking I have no clue at all which version of the patch will
> be used by the 2.10.1 recipe. 

glibc-2.4/ one - check FILESPATHPKG setting in glibc_2.10.1.bb recipe.

> The only ways to find out is to study the class code that does the patch or
> to actually build the package (in the hope it selects the patch in a
> deterministic way). 

I did "grep FILES glibc/*" to find out.

> I don't think it is good that if someone is debugging a problem that they
> should have such a hard time to find out what version of a file is
> actually used
 
> My proposal:
> - only apply patches (seek for patches) in the recipe dir (e.g. in the
> example for glibc_2.10.1.bb this would be glibc-2.10.1) and in the
> files directory

It is not only patches. It is everything in SRC_URI. And we have this 
mechanism since beginning.
 
> (optionally we might allow for a mechanism that allows specifying
> patches for higher level recipes; e.g. glibc_2.10.1 could look in
> glibc-2.10.1, glibc-2.10, glibc-2, glibc and files).

We have such mechanism already - it is FILESPATHPKG and related vars.
 
> How do people feel about this? Any implementation hints?

Why implement when it is already implemented?

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] patch file location

[Frans Meulenbroeks]

2010/6/22 Marcin Juszkiewicz <marcin@juszkiewicz.com.pl>:
> Dnia wtorek, 22 czerwca 2010 o 09:03:43 Frans Meulenbroeks napisał(a):
>> I'd like to draw the attention to the location of patch files.
>> My original understanding was that these should be in either the files
>> dir (if they apply to all), or in a dir with the name of the recipe
>> (replacing the _ with a - ).
>>
>> And I kind-a assumed that if a patch is in a recipe dir it would have
>> priority above a version in the files dir.
>
> This is controlled by FILESPATHPKG and OVERRIDES.
>
>> Frankly speaking I have no clue at all which version of the patch will
>> be used by the 2.10.1 recipe.
>
> glibc-2.4/ one - check FILESPATHPKG setting in glibc_2.10.1.bb recipe.
>
>> The only ways to find out is to study the class code that does the patch or
>> to actually build the package (in the hope it selects the patch in a
>> deterministic way).
>
> I did "grep FILES glibc/*" to find out.
>
>> I don't think it is good that if someone is debugging a problem that they
>> should have such a hard time to find out what version of a file is
>> actually used
>
>> My proposal:
>> - only apply patches (seek for patches) in the recipe dir (e.g. in the
>> example for glibc_2.10.1.bb this would be glibc-2.10.1) and in the
>> files directory
>
> It is not only patches. It is everything in SRC_URI. And we have this
> mechanism since beginning.
>
>> (optionally we might allow for a mechanism that allows specifying
>> patches for higher level recipes; e.g. glibc_2.10.1 could look in
>> glibc-2.10.1, glibc-2.10, glibc-2, glibc and files).
>
> We have such mechanism already - it is FILESPATHPKG and related vars.
>
>> How do people feel about this? Any implementation hints?
>
> Why implement when it is already implemented?
>

hrw thanks for your clarification.
Guess the confusion is caused because FILESPATHPKG does not seem to be
documented, so I was unaware of its existence and meaning.

http://docs.openembedded.org/usermanual/html/recipes_directories.html#recipes_filespath_dir
does not mention it but does explain the standard structure.
Guess something could be added there

BTW: I feel referring to patches in dirs of other versions (like
2.10.1 referring to 2.4) is not too clear and somewhat more
error-prone, and should be discouraged.

Did a quick grep. On 47 places there is a FILESPATHPKG.
Some just do things like: :FILESPATHPKG .= ":gcc-$PV (actually
shouldn't that be gcc-${PV} )
That might be added to the default search path.

(actually even found a forward reference:
recipes/gcc/gcc-4.1.0.inc:FILESPATHPKG .= ":gcc-4.1.1") :-)

Frans.

Re: [RFC] patch file location

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22-06-10 09:03, Frans Meulenbroeks wrote:
> I'd like to draw the attention to the location of patch files.
> My original understanding was that these should be in either the files
> dir (if they apply to all)

No, 'files' should be avoided. When we start rearranging the directory
structure every file in 'files' will need to get checked to see to which
recipe it applies. If a patch or file is for multiple versions of recipe
foobar, place it in 'foobar/'.
Pretty much the only valid use of 'files/' is when one file is shared
between multiple different recipes (foobar_1.bb, qux_5.bb, etc), like
the gtk-doc.m4 for gnome stuff.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMIHaGMkyGM64RGpERAi+/AJ4xW0TDYMPM1zMC8tTfurDopDQpsQCaAycX
cKR3NrAdFT8lhz785DrKyeg=
=kY64
-----END PGP SIGNATURE-----

Re: [RFC] patch file location

[Phil Blundell]

On Tue, 2010-06-22 at 09:03 +0200, Frans Meulenbroeks wrote:
> Frankly speaking I have no clue at all which version of the patch will
> be used by the 2.10.1 recipe. The only ways to find out is to study
> the class code that does the patch or to actually build the package
> (in the hope it selects the patch in a deterministic way). I don't
> think it is good that if someone is debugging a problem that they
> should have such a hard time to find out what version of a file is
> actually used

See glibc_2.10.1.bb:

FILESPATHPKG =. "glibc-2.4:"

So, the answer is that it will use the version from the glibc-2.4
directory.  

I think the semantics of FILESPATHPKG are documented in the manual.  If
they're not, that is an oversight and should indeed be corrected.

> (optionally we might allow for a mechanism that allows specifying
> patches for higher level recipes; e.g. glibc_2.10.1 could look in
> glibc-2.10.1, glibc-2.10, glibc-2, glibc and files).

You can already do this with a suitable FILESPATHPKG setting, I think.

p.

Re: [RFC] patch file location

[Frans Meulenbroeks]

2010/6/22 Phil Blundell <philb@gnu.org>:
> On Tue, 2010-06-22 at 09:03 +0200, Frans Meulenbroeks wrote:
>> Frankly speaking I have no clue at all which version of the patch will
>> be used by the 2.10.1 recipe. The only ways to find out is to study
>> the class code that does the patch or to actually build the package
>> (in the hope it selects the patch in a deterministic way). I don't
>> think it is good that if someone is debugging a problem that they
>> should have such a hard time to find out what version of a file is
>> actually used
>
> See glibc_2.10.1.bb:
>
> FILESPATHPKG =. "glibc-2.4:"
>
> So, the answer is that it will use the version from the glibc-2.4
> directory.
>
> I think the semantics of FILESPATHPKG are documented in the manual.  If
> they're not, that is an oversight and should indeed be corrected.

Couldn't find it and googling for
site:docs.openembedded.org FILESPATHPKG
did not return any results

FM
>
>> (optionally we might allow for a mechanism that allows specifying
>> patches for higher level recipes; e.g. glibc_2.10.1 could look in
>> glibc-2.10.1, glibc-2.10, glibc-2, glibc and files).
>
> You can already do this with a suitable FILESPATHPKG setting, I think.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>