Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: wanting to clarify patch mechanics
Date: Sat, 7 Jul 2012 12:15:49 +0200	[thread overview]
Message-ID: <20120707101549.GI3708@jama.jama.net> (raw)
In-Reply-To: <alpine.DEB.2.02.1207070547020.17784@oneiric>

[-- 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 --]

  reply	other threads:[~2012-07-07 10:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-07 10:04 wanting to clarify patch mechanics Robert P. J. Day
2012-07-07 10:15 ` Martin Jansa [this message]
2012-07-07 10:28   ` Robert P. J. Day

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120707101549.GI3708@jama.jama.net \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox