[Buildroot] RFC: package patching

Thomas De Schampheleire patrickdepinguin+buildroot at gmail.com
Wed Nov 16 06:44:54 UTC 2011


On Tue, Nov 15, 2011 at 10:28 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> Le Tue, 15 Nov 2011 19:14:38 +0000,
> Arnout Vandecappelle <arnout at mind.be> a écrit :
>
>> > Yes, I know - We hit this with E.G. busybox in the past. I would go
>> > for the versioned-patches-in-subdir, as we (luckily) only support
>> > multiple versions for a limited number of packages.
>>
>>  While we're at it, I would also make it policy to not include the
>> version number in the patch, except for packages with multiple active
>> versions.  Now, when you're upgrading a package, you also have to do
>> a lot of renames of patches.
>
> I agree with both Thomas and Arnout. Thomas is right on the fact that
> we should clarify the patching logic in the package infrastructure, but
> this clarification should also come together with a clarification of
> the best practices for storing patches for packages.
>
> As Arnout suggests, I think that most packages should just have patches
> whose filename do not contain the version. Only packages that support
> multiple versions would have subdirectories.

I'm not sure if this is so black-and-white. If a patch backports a
change from 1.2.3 to 1.2.2, then IMO the patch should really be named
1.2.2, even if only 1.2.2 is present in Buildroot. If it is named
without version, then it will also be taken along when bumping the
package (and possibly but not necessarily cause a patch conflict).
Only in cases were the change made by the patch is generic and not
intended for a specific version, should we remove the version from the
patch name.

>
> At the same time, we should also probably generalize the usage of patch
> numbering, in order to have a clear order of the patches. I.e,
> something such as:
>
>        foobar-0001-something.patch
>        foobar-0002-somethingelse.patch
>

Ok with me.

Best regards,
Thomas



More information about the buildroot mailing list