[oe] trying to simplify the patch/apply/pnum/striplevel jungle

Robert P. J. Day rpjday at crashcourse.ca
Sat Jun 5 06:53:28 UTC 2010


  just working my way thru the OE manual and source and it's clear
that there could be some cleanup of superfluous or deprecated patch
info.  so can someone clarify whether my understanding of the
following is correct?

pnum/striplevel
===============

  first, "pnum=" is deprecated and has been replaced by "striplevel="
and, in any event, given that the default patchlevel is one, it's
unnecessary for either of those to be there while being set to one.  i
don't see any cleanup in the source itself, but the manual could be
updated on that point, as in
(http://docs.openembedded.org/usermanual/html/src_uri_variable.html):

"pnum

    By default patches are applied with the "-p 1" parameter, which
strips off the first directory of the pathname in the patches. This
option is used to explicitly control the value passed to "-p". The
most typical use is when the patches are relative to the source
directory already and need to be applied using "-p 0", in which case
the "pnum=0" option is supplied."

  obviously, the manual could mention that that's deprecated and
should additionally describe striplevel.

  in fact, given that there's no reference to pnum= in the OE source,
perhaps support for (and all references to) "pnum" can be dropped
entirely unless other (non-OE) projects still depend on it.

  in any event, i can submit a patch to update the manual.

patch/apply
===========

  as i read it, "patch=" has also been deprecated and, once again, the
manual could stand to be updated (on that same page above):

"patch

    Used as "patch=1" to define this file as a patch file. Patch files
will be copied to ${S}/patches and then applied to source from within
the source directory, ${S}."

  there's still some "patch=" content in the OE source, such as:

recipes/udev/udev_100.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
recipes/udev/udev_100.bb:	    file://flags.patch;patch=1 \
recipes/udev/udev_100.bb:	    file://mtd-exclude-persistent.patch;patch=1 \
recipes/udev/udev_092.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
recipes/udev/udev_092.bb:	    file://flags.patch;patch=1 \
recipes/udev/udev_092.bb:	    file://udevsynthesize.patch;patch=1 \
recipes/udev/udev_092.bb:            file://arm_inotify_fix.patch;patch=1 \
recipes/udev/udev_092.bb:	    file://mtd-exclude-persistent.patch;patch=1 \
recipes/udev/udev_097.bb:SRC_URI += "file://noasmlinkage.patch;patch=1 \
recipes/udev/udev_097.bb:	    file://flags.patch;patch=1 \

  what i need clarified is the possible usage of "apply=" WRT patches.
as i read classes/patch.bblclass, it seems like:

  * any file whose name ends in either ".diff" or ".patch" is
    considered a patch and will, by default, be processed that way

  * "apply=no" is only necessary to *prevent* default
    processing of a ".patch" or ".diff" file

  * "apply=yes" is only necessary to *force* processing of a file
    that *doesn't* end with one of those suffixes.  in short,
    something like this is redundant:

    recipes/socketcan/libsocketcan_0.0.7.bb:SRC_URI +=
      "file://install-can_netlink.h.patch;apply=yes \ ...
                                          ^^^^^^^^^ redundant

is all that about right?

pname
=====

  not much reference to that in the source, but there is some:

$ grep -r pname= *
recipes/linux/ixp4xx-kernel.inc:
patch_uri.append("${KERNELORG_MIRROR}/pub/linux/kernel/v%s/testing/patch-%s.bz2;apply=yes;pname=%s;name=rcpatch"
% (major, pname, pname))
recipes/linux/ixp4xx-kernel.inc:
patch_uri.append("${KERNELORG_MIRROR}/pub/linux/kernel/v%s/snapshots/patch-%s.bz2;apply=yes;pname=%s;name=gitpatch"
% (major, pname, pname))
recipes/linux/ixp4xx-kernel.inc:
patch_uri.append("${KERNELORG_MIRROR}/pub/linux/kernel/people/akpm/patches/%s/%s/%s/%s.bz2;apply=yes;pname=%s;name=mmpatch"
% (major, base, pname, pname, pname))

seems pretty self-explanatory -- patch processing for, in these cases,
a tarball where one needs to define the name of the patch accordingly.
i'm assuming that, in cases like this where the suffix is not a patch
suffix, you *must* specify "apply=yes", correct?  in other words, it
would make no sense to just specify pname= without the accompanying
apply=, is that right?  there's no mention of that in the OE manual on
that same page.  should there be?  or is that so specialized and
unusual that it can be left unexplained?

  i think that's all i'm curious about regarding the source or the
manual.  i can throw together a few patches to clean up the more
obvious stuff.

rday



-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================




More information about the Openembedded-devel mailing list