Patchwork [02/11] manual: minor fix in patch-policy.txt

login
register
mail settings
Submitter Samuel Martin
Date Feb. 25, 2013, 9:31 p.m.
Message ID <677f6fbb5a9c1994131975c171a285c4335c38d8.1361827174.git.s.martin49@gmail.com>
Download mbox | patch
Permalink /patch/223048/
State Superseded
Headers show

Comments

Samuel Martin - Feb. 25, 2013, 9:31 p.m.
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
---
 docs/manual/patch-policy.txt | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
Thomas Petazzoni - Feb. 26, 2013, 8:29 a.m.
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
Samuel Martin - Feb. 26, 2013, 9:44 a.m.
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,
Thomas Petazzoni - Feb. 26, 2013, 11:01 a.m.
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
Samuel Martin - Feb. 26, 2013, 11:15 a.m.
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,

Patch

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.