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 ======================================================================== _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
