| Message ID | 677f6fbb5a9c1994131975c171a285c4335c38d8.1361827174.git.s.martin49@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
Dear Samuel Martin, On Mon, 25 Feb 2013 22:31:22 +0100, Samuel Martin wrote: > +- If a patch does some package version fixes, this should be documented in the > +commit message of the patch itself (or the message prepended to the 'diff' > +itself). I am not sure to understand this part. > +* Otherwise, patch files matching +<packagename>-<description>.patch+ > + are applied following the +ls+ command order. Shouldn't we be enforcing a <packagename>-<number>-<description>.patch policy, in order to ensure that patches are applied in the right order? Best regards, Thomas
Hi Thomas, 2013/2/26 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Samuel Martin, > > On Mon, 25 Feb 2013 22:31:22 +0100, Samuel Martin wrote: > >> +- If a patch does some package version fixes, this should be documented in the >> +commit message of the patch itself (or the message prepended to the 'diff' >> +itself). > > I am not sure to understand this part. I don't know how to explain this clearly. My point is, for some packages, BR does not provide the latest version, but some fix may be available upstream, so they have been backported in BR (e.g.: package/libglib2/libglib2-make-codegen-python2-python3-compliant.patch). Any suggestion to explain this point in a better way is welcome. > >> +* Otherwise, patch files matching +<packagename>-<description>.patch+ >> + are applied following the +ls+ command order. > > Shouldn't we be enforcing a <packagename>-<number>-<description>.patch > policy, in order to ensure that patches are applied in the right order? Well, here I stick to the current apply-patches.sh implementation. Regards,
Dear Samuel Martin, On Tue, 26 Feb 2013 10:44:39 +0100, Samuel Martin wrote: > >> +- If a patch does some package version fixes, this should be documented in the > >> +commit message of the patch itself (or the message prepended to the 'diff' > >> +itself). > > > > I am not sure to understand this part. > I don't know how to explain this clearly. > > My point is, for some packages, BR does not provide the latest version, > but some fix may be available upstream, so they have been backported in BR > (e.g.: package/libglib2/libglib2-make-codegen-python2-python3-compliant.patch). > > Any suggestion to explain this point in a better way is welcome. I don't understand why you would want to put this here in the documentation. What you're saying is just a detail on what the patch could possibly contain (i.e a backport from upstream versus a Buildroot-specific hack for cross-compilation), I don't see what it changes in terms of patch policy. > >> +* Otherwise, patch files matching +<packagename>-<description>.patch+ > >> + are applied following the +ls+ command order. > > > > Shouldn't we be enforcing a <packagename>-<number>-<description>.patch > > policy, in order to ensure that patches are applied in the right order? > Well, here I stick to the current apply-patches.sh implementation. The current apply-patches.sh implementation takes the patches in alphabetical order, which is why it is important to have the patches numbered to make sure that the patches are applied in a well-known order, and not an order based on the <description> field alphabetical sorting. Best regards, Thomas
Hi Thomas, 2013/2/26 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>: > Dear Samuel Martin, > > On Tue, 26 Feb 2013 10:44:39 +0100, Samuel Martin wrote: > >> >> +- If a patch does some package version fixes, this should be documented in the >> >> +commit message of the patch itself (or the message prepended to the 'diff' >> >> +itself). >> > >> > I am not sure to understand this part. >> I don't know how to explain this clearly. >> >> My point is, for some packages, BR does not provide the latest version, >> but some fix may be available upstream, so they have been backported in BR >> (e.g.: package/libglib2/libglib2-make-codegen-python2-python3-compliant.patch). >> >> Any suggestion to explain this point in a better way is welcome. > > I don't understand why you would want to put this here in the > documentation. What you're saying is just a detail on what the patch > could possibly contain (i.e a backport from upstream versus a > Buildroot-specific hack for cross-compilation), I don't see what it > changes in terms of patch policy. Fair enough, I'll drop this point. > >> >> +* Otherwise, patch files matching +<packagename>-<description>.patch+ >> >> + are applied following the +ls+ command order. >> > >> > Shouldn't we be enforcing a <packagename>-<number>-<description>.patch >> > policy, in order to ensure that patches are applied in the right order? >> Well, here I stick to the current apply-patches.sh implementation. > > The current apply-patches.sh implementation takes the patches in > alphabetical order, which is why it is important to have the patches > numbered to make sure that the patches are applied in a well-known > order, and not an order based on the <description> field alphabetical > sorting. Well, explicit numbering is better than implicit, so should be the doc. I'll fix it and re-spin this patch. Regards,
diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt index 14c6efc..114c81e 100644 --- a/docs/manual/patch-policy.txt +++ b/docs/manual/patch-policy.txt @@ -40,6 +40,14 @@ A +series+ file, as used by +quilt+, may also be added in the package directory. In that case, the +series+ file defines the patch application order. +.Notes +- The patch files coming with Buildroot should not contain any package version +reference in their filename. +- If a patch does some package version fixes, this should be documented in the +commit message of the patch itself (or the message prepended to the 'diff' +itself). + + How patches are applied ~~~~~~~~~~~~~~~~~~~~~~~ @@ -56,8 +64,8 @@ How patches are applied * If a +series+ file exists in the package directory, then patches are applied according to the +series+ file; + -* Otherwise, patch files matching `<packagename>-*.patch` are applied - following the +ls+ command order. +* Otherwise, patch files matching +<packagename>-<description>.patch+ + are applied following the +ls+ command order. . Run the +<packagename>_POST_PATCH_HOOKS+ commands if defined.
Signed-off-by: Samuel Martin <s.martin49@gmail.com> --- docs/manual/patch-policy.txt | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)