wanting to clarify patch mechanics

wanting to clarify patch mechanics

[Robert P. J. Day]

  not sure if there's a more comprehensive coverage of how OE patches
work than the brief discussion in the bitbake user manual, but i'd
like to clarify the variations just so i can document them.

  here's what's in the bitbake manual that seems to be the entire
coverage of patches:

SRC_URI= "file://relativefile.patch"
SRC_URI= "file://relativefile.patch;this=ignored"
SRC_URI= "file:///Users/ich/very_important_software"

and so, to questions.

  first, what is this "this=ignored"?  does that still exist?  is it
equivalent to "apply=no"?  i don't see a single example of
"this=ignored" anywhere throughout oe-core, but i see a single example
of "apply=no" in net-tools_1.60-23.bb.

  speaking of apply, it would seem that "apply=yes" is redundant, is
that correct?  there are a couple dozen examples of that throughout
oe-core, mostly in the bash recipe file.  is there anything subtle
about that parameter, or is it truly superfluous?

  there's no mention of the "striplevel" parameter in the manual,
which i think would be useful, and that its default value is "1".  and
i can see the warning that "pnum" is deprecated in favour of
"striplevel", but at the moment, i see not a single usage of "pnum"
and wonder if that warning can just be tossed and support for "pnum"
abandoned entirely.  (there's not a single usage of "pnum" anywhere in
the entire yocto pull, either.  just an observation.)


  i think that's all i had for now.  anything else about patches worth
writing down?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: wanting to clarify patch mechanics

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]

On Sat, Jul 07, 2012 at 06:04:07AM -0400, Robert P. J. Day wrote:
> 
>   not sure if there's a more comprehensive coverage of how OE patches
> work than the brief discussion in the bitbake user manual, but i'd
> like to clarify the variations just so i can document them.
> 
>   here's what's in the bitbake manual that seems to be the entire
> coverage of patches:
> 
> SRC_URI= "file://relativefile.patch"
> SRC_URI= "file://relativefile.patch;this=ignored"
> SRC_URI= "file:///Users/ich/very_important_software"
> 
> and so, to questions.
> 
>   first, what is this "this=ignored"?  does that still exist?  is it
> equivalent to "apply=no"?  i don't see a single example of
> "this=ignored" anywhere throughout oe-core, but i see a single example
> of "apply=no" in net-tools_1.60-23.bb.
> 
>   speaking of apply, it would seem that "apply=yes" is redundant, is
> that correct?  there are a couple dozen examples of that throughout
> oe-core, mostly in the bash recipe file.  is there anything subtle
> about that parameter, or is it truly superfluous?

apply=yes is default for *.patch and .diff, for files with other
extension it's still needed (e.g. those entries in bash)

so there is only a few redundant usages in oe-core:
meta/recipes-connectivity/portmap/portmap.inc:  file://make.patch;apply=yes"
meta/recipes-core/eggdbus/eggdbus_0.6.bb:          file://gtk-doc.patch;apply=yes \
meta/recipes-core/eggdbus/eggdbus_0.6.bb:           file://marshal.patch;apply=yes \
meta/recipes-graphics/libxsettings-client/libxsettings-client_0.10.bb:        file://link-x11.patch;apply=yes \
meta/recipes-graphics/xorg-proto/calibrateproto_git.bb:           file://fix.patch;apply=yes"
meta/recipes-sato/leafpad/leafpad_0.8.18.1.bb:SRC_URI_append_poky = " file://owl-menu.patch;apply=yes "
meta/recipes-sato/pimlico/contacts.inc:SRC_URI_append_poky = " file://contacts-owl-window-menu.patch;apply=yes "
meta/recipes-sato/pimlico/dates.inc:SRC_URI_append_poky = " file://dates-owl-window-menu.patch;apply=yes "
meta/recipes-sato/settings-daemon/settings-daemon_git.bb:           file://addsoundkeys.patch;apply=yes \
meta/recipes-support/libcroco/libcroco_0.6.3.bb:SRC_URI_append = " file://croco.patch;apply=yes \

some devs cleanup those when doing upgrades.. if it bothers you enough 
you can send patch removing those...


>   there's no mention of the "striplevel" parameter in the manual,
> which i think would be useful, and that its default value is "1".  and
> i can see the warning that "pnum" is deprecated in favour of
> "striplevel", but at the moment, i see not a single usage of "pnum"
> and wonder if that warning can just be tossed and support for "pnum"
> abandoned entirely.  (there's not a single usage of "pnum" anywhere in
> the entire yocto pull, either.  just an observation.)

pnum is still used e.g. in meta-oe vim recipe.

Cheers,

> 
> 
>   i think that's all i had for now.  anything else about patches worth
> writing down?
> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: wanting to clarify patch mechanics

[Robert P. J. Day]

On Sat, 7 Jul 2012, Martin Jansa wrote:

> On Sat, Jul 07, 2012 at 06:04:07AM -0400, Robert P. J. Day wrote:
> >
> >   speaking of apply, it would seem that "apply=yes" is redundant, is
> > that correct?  there are a couple dozen examples of that throughout
> > oe-core, mostly in the bash recipe file.  is there anything subtle
> > about that parameter, or is it truly superfluous?
>
> apply=yes is default for *.patch and .diff, for files with other
> extension it's still needed (e.g. those entries in bash)

  ah, that's useful to know, thanks.

> so there is only a few redundant usages in oe-core:
> meta/recipes-connectivity/portmap/portmap.inc:  file://make.patch;apply=yes"
> meta/recipes-core/eggdbus/eggdbus_0.6.bb:          file://gtk-doc.patch;apply=yes \
> meta/recipes-core/eggdbus/eggdbus_0.6.bb:           file://marshal.patch;apply=yes \
> meta/recipes-graphics/libxsettings-client/libxsettings-client_0.10.bb:        file://link-x11.patch;apply=yes \
> meta/recipes-graphics/xorg-proto/calibrateproto_git.bb:           file://fix.patch;apply=yes"
> meta/recipes-sato/leafpad/leafpad_0.8.18.1.bb:SRC_URI_append_poky = " file://owl-menu.patch;apply=yes "
> meta/recipes-sato/pimlico/contacts.inc:SRC_URI_append_poky = " file://contacts-owl-window-menu.patch;apply=yes "
> meta/recipes-sato/pimlico/dates.inc:SRC_URI_append_poky = " file://dates-owl-window-menu.patch;apply=yes "
> meta/recipes-sato/settings-daemon/settings-daemon_git.bb:           file://addsoundkeys.patch;apply=yes \
> meta/recipes-support/libcroco/libcroco_0.6.3.bb:SRC_URI_append = " file://croco.patch;apply=yes \
>
> some devs cleanup those when doing upgrades.. if it bothers you enough
> you can send patch removing those...

  it didn't really bother me so much as i just wanted to make sure it
didn't represent something subtle that changed the expected behaviour,
and your earlier explanation clarified that.  i might send a patch
along later.  thanks for the clarification.

  today's going to be a very oe-oriented day so expect more nitpicking
pedantry.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================