From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 11/16 v5] core/legal-info: renumber saved patches
Date: Sat, 19 Mar 2016 16:05:46 +0100 [thread overview]
Message-ID: <20160319160546.647dd3e4@free-electrons.com> (raw)
In-Reply-To: <239b97de0688ee582fee97a67f9534cd8ad29493.1457718289.git.yann.morin.1998@free.fr>
Dear Yann E. MORIN,
On Fri, 11 Mar 2016 18:49:24 +0100, Yann E. MORIN wrote:
> Patches we save can come from various locations;
> - bundled with Buildroot
> - downloaded
> - from one or more global-patch-dir
>
> It is possible that two patches lying into different locations have the
> same basename, like so (first is bundled, second is from an hypothetical
> global-patch-dir):
> package/foo/0001-fix-Makefile.patch
> /path/to/my/patches/foo/0001-fix-Makefile.patch
>
> In that case, we'd save only the second patch, overwriting the first.
>
> We fix that by forcibly prefixing saved patches with a new numbering, to
> guarantee the unicity of saved files.
>
> The unfortunate side-effects are that:
> - most saved patches will be twice-numbered,
> - the series file is now redundant.
>
> While the former is mostly not nice-looking, we shouldn't try to strip
> any leading numbering, as that might not be a numbering (e.g.
> 42-retries.patch which is a patch add 42 retries).
>
> The latter is not really problematic. A lot of tools (and people) can
> work with, and prefer to have a series file.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>
> Cc: Arnout Vandecappelle <arnout@mind.be>
>
> ---
> Note that I've made this a separate change, not because the patch would
> be too complex if squahed with the previous, but rather to have a more
> detailed commit log about the reason for the renumbering; squashing the
> two changes together would make for a really long commit log, at the
> risk of being more difficult to follow.
>
> Note: an alternative solution was suggested by Luca (and Arnout?), which
> would be to check that no two patches have the same basename or bail-out
> otherwise. I choose to keep the renumbering, because it follows the path
> of least resistance (i.e. it does not break existing setups).
I second the position of Luca and Arnout. This renumbering is
complicated and leads to ugly patch names that no longer match the
original file name. So please simply bail-out if two patches have the
same name. It's highly unlikely, so I don't think we should renumber
all the patches and have different file names just to avoid this
unlikely case.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-03-19 15:05 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-11 17:49 [Buildroot] [PATCH 00/16 v5] legal-info improvements and completeness (branch yem/legal-3) Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 01/16 v5] toolchain/external: add hashes for actual sources Yann E. MORIN
2016-03-19 15:31 ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 02/16 v5] core/pkg-utils: add macro to hardlink-or-copy Yann E. MORIN
2016-03-19 14:23 ` Thomas Petazzoni
2016-03-19 16:08 ` Arnout Vandecappelle
2016-03-19 23:33 ` Yann E. MORIN
2016-03-20 13:21 ` Thomas Petazzoni
2016-03-22 22:32 ` Arnout Vandecappelle
2016-03-19 23:11 ` Yann E. MORIN
2016-03-20 13:29 ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 03/16 v5] core/legal-info: use the macro to install source archives Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 04/16 v5] core/pkg-generic: reorder variables definitions for legal-info Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 05/16 v5] core/legal-info: ensure legal-info works in off-line mode Yann E. MORIN
2016-03-19 14:47 ` Thomas Petazzoni
2016-03-19 18:18 ` Yann E. MORIN
2016-04-28 21:57 ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 06/16 v5] core/pkg-generic: add variable to store the package rawname-version Yann E. MORIN
2016-03-19 14:48 ` Thomas Petazzoni
2016-03-19 18:20 ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 07/16 v5] core/legal-info: install source archives in their own sub-dir Yann E. MORIN
2016-03-19 14:51 ` Thomas Petazzoni
2016-03-11 17:49 ` [Buildroot] [PATCH 08/16 v5] core/legal-info: add package version to license directory Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 09/16 v5] core/apply-patches: store full path of applied patches Yann E. MORIN
2016-03-19 15:03 ` Thomas Petazzoni
2016-03-19 18:51 ` Yann E. MORIN
2016-03-19 22:37 ` Yann E. MORIN
2016-03-20 13:47 ` Thomas Petazzoni
2016-03-20 16:28 ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 10/16 v5] core/legal-info: also save patches Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 11/16 v5] core/legal-info: renumber saved patches Yann E. MORIN
2016-03-19 15:05 ` Thomas Petazzoni [this message]
2016-03-19 23:34 ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 12/16 v5] core/legal-info: also save extra downloads Yann E. MORIN
2016-03-19 15:14 ` Thomas Petazzoni
2016-03-20 16:33 ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 13/16 v5] core/legal-info: generate a hash of all saved files Yann E. MORIN
2016-03-19 15:21 ` Thomas Petazzoni
2016-03-19 23:40 ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 14/16 v5] core/legal-info: allow ignoring packages from the legal-info Yann E. MORIN
2016-03-19 15:29 ` Thomas Petazzoni
2016-03-19 23:48 ` Yann E. MORIN
2016-03-11 17:49 ` [Buildroot] [PATCH 15/16 v5] core/pkg-virtual: ignore from legal-info output Yann E. MORIN
2016-03-27 20:47 ` Arnout Vandecappelle
2016-03-11 17:49 ` [Buildroot] [PATCH 16/16 v5] legal-info: explicitly state how patches are licensed Yann E. MORIN
2016-03-27 20:49 ` Arnout Vandecappelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160319160546.647dd3e4@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.