Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 09/13 v2] core/legal-info: also save patches
Date: Thu, 17 Dec 2015 11:45:46 +0100	[thread overview]
Message-ID: <5672925A.5080400@lucaceresoli.net> (raw)
In-Reply-To: <a0a187ba70eeb0c27ae84cbc52d823d3ca445a83.1450031251.git.yann.morin.1998@free.fr>

Dear Yann,

Yann E. MORIN wrote:
> Currently, the legal-info infra only saves the source archive of a
> package. However, that's not enough as we may apply some patches on
> packages sources.
>
> We do suggest users to also redistribute the Buildroot sources as part
> of their compliance distribution, so the patches bundled in Buildroot
> would indeed be included in the compliance distribution.
>
> However, that's still not enough, since we may download some patches, or
> the user may use a global patch directory. Patches in there might not
> end up in the compliance distribution, and there are risks of
> non-conformity.
>
> So, always include patches alongside the source archive.
>
> To ensure reproducibility, we also generate a series file, so patches
> can be re-applied in the correct order.
>
> We get the list of patches to include from the list of patches that were
> applied by the package infrastructure (via the apply-patches support
> script). So, we need to get packages properly extracted and patched
> before we can save their legal-info, not just in the case they define
> _LICENSE_FILES.
>
> Update the legal-info header accordingly.
>
> Note: this means that, when a package is not patched and defines no
> LICENSE_FILES, we will extract and patch it for nothing. There is no
> easy way to know whether we have to patch a package or not. We can only
> either duplicate the logic to detect patches (bad) or rely on the infra
> actually patching the package. Also, a vast majority of packages are
> either patched, or define _LICENSE_FILES, so it is best and easiest to
> always extract and patch them prior to legal-info.
>
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Luca Ceresoli <luca@lucaceresoli.net>
>
> ---
> Changes v1 -> v2;
>    - don't recompute rawname-version needlessly  (Luca)
> ---
>   package/pkg-generic.mk           | 12 +++++++-----
>   support/legal-info/README.header |  3 +--
>   2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index 9b9a27f..f873e9c 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -760,12 +760,10 @@ $(2)_MANIFEST_LICENSE_FILES = $$($(2)_LICENSE_FILES)
>   endif
>   $(2)_MANIFEST_LICENSE_FILES ?= not saved
>
> -# If the package declares _LICENSE_FILES, we need to extract it,
> -# for overriden, local or normal remote packages alike, whether
> -# we want to redistribute it or not.
> -ifneq ($$($(2)_LICENSE_FILES),)
> +# We need to extract and patch a package to be able to retrieve its
> +# license files (if any) and the list of patches applied to it (if
> +# any).
>   $(1)-legal-info: $(1)-patch
> -endif
>
>   # We only save the sources of packages we want to redistribute, that are
>   # non-local, and non-overriden. So only store, in the manifest, the tarball
> @@ -827,6 +825,10 @@ ifeq ($$($(2)_REDISTRIBUTE),YES)
>   	$$(Q)$$(call hardlink-copy,\
>   		     $$(DL_DIR)/$$($(2)_ACTUAL_SOURCE_TARBALL),\
>   		     $$($(2)_REDIST_SOURCES_DIR))
> +	$$(Q)while read f; do \
> +		$$(call hardlink-copy,$$$${f},$$($(2)_REDIST_SOURCES_DIR)) || exit 1; \
> +		printf "%s\n" "$$$${f##*/}" >>$$($(2)_REDIST_SOURCES_DIR)/series || exit 1; \
> +	done <$$($(2)_DIR)/.applied_patches_list
>   endif # redistribute
>
>   endif # other packages
> diff --git a/support/legal-info/README.header b/support/legal-info/README.header
> index d07c45d..4d7fd7c 100644
> --- a/support/legal-info/README.header
> +++ b/support/legal-info/README.header
> @@ -16,8 +16,7 @@ This material is composed of the following items.
>      need to collect it manually.
>    * The source code for all packages; this has been saved in the sources/
>      subdirectory (except for the non-redistributable packages, which have not
> -   been saved); patches applied to some packages by Buildroot are included in
> -   the Buildroot sources and were not duplicated in the sources/ subdirectory.
> +   been saved).

Now we could explicitly state we also save patches. E.g. changing the
above bullet to:

  * The original source code for all packages; this has been saved in...
        ^^^^^^^^

And adding:

  * The patches applied to the source code before building it, along with
    a file named 'series' that lists the same patches in the order they
    have been applied.

But this can be done in a later commit, so:

Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Tested-by: Luca Ceresoli <luca@lucaceresoli.net>

-- 
Luca

  reply	other threads:[~2015-12-17 10:45 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-13 18:35 [Buildroot] [PATCH 0/13 v2] legal-info improvements and completeness (branch yem/legal-2) Yann E. MORIN
2015-12-13 18:35 ` [Buildroot] [PATCH 01/13 v2] core/legal-info: update the legal-info report header Yann E. MORIN
2015-12-16 22:20   ` Arnout Vandecappelle
2015-12-13 18:35 ` [Buildroot] [PATCH 02/13 v2] core/pkg-utils: add macro to hardlink-or-copy Yann E. MORIN
2015-12-16 22:21   ` Arnout Vandecappelle
2015-12-13 18:35 ` [Buildroot] [PATCH 03/13 v2] core/legal-info: use the macro to install source archives Yann E. MORIN
2015-12-16 22:23   ` Arnout Vandecappelle
2015-12-13 18:35 ` [Buildroot] [PATCH 04/13 v2] core/legal-info: ensure legal-info works in off-line mode Yann E. MORIN
2015-12-16 11:30   ` Luca Ceresoli
2015-12-16 22:47     ` Luca Ceresoli
2015-12-16 23:05       ` Yann E. MORIN
2015-12-16 23:09         ` Arnout Vandecappelle
2015-12-16 23:13           ` Yann E. MORIN
2015-12-16 23:19   ` Arnout Vandecappelle
2015-12-18 22:11     ` Yann E. MORIN
2015-12-18 22:30       ` Yann E. MORIN
2015-12-13 18:35 ` [Buildroot] [PATCH 05/13 v2] core/pkg-generic: add variable to store the package rawname-version Yann E. MORIN
2015-12-16 12:07   ` Luca Ceresoli
2015-12-16 23:44   ` Arnout Vandecappelle
2015-12-13 18:35 ` [Buildroot] [PATCH 06/13 v2] core/legal-info: install source archives in their own sub-dir Yann E. MORIN
2015-12-16 23:56   ` Arnout Vandecappelle
2015-12-18 22:53     ` Yann E. MORIN
2015-12-19  0:02       ` Arnout Vandecappelle
2015-12-13 18:35 ` [Buildroot] [PATCH 07/13 v2] core/legal-info: add package version to license directory Yann E. MORIN
2015-12-16 14:21   ` Luca Ceresoli
2015-12-13 18:35 ` [Buildroot] [PATCH 08/13 v2] core/apply-patches: store full path of applied patches Yann E. MORIN
2015-12-17 10:44   ` Luca Ceresoli
2015-12-13 18:35 ` [Buildroot] [PATCH 09/13 v2] core/legal-info: also save patches Yann E. MORIN
2015-12-17 10:45   ` Luca Ceresoli [this message]
2015-12-18 23:07     ` Yann E. MORIN
2015-12-13 18:35 ` [Buildroot] [PATCH 10/13 v2] core/legal-info: also save extra downloads Yann E. MORIN
2015-12-17 10:57   ` Luca Ceresoli
2015-12-13 18:35 ` [Buildroot] [PATCH 11/13 v2] core/legal-info: generate a hash of all saved files Yann E. MORIN
2015-12-13 18:35 ` [Buildroot] [PATCH 12/13 v2] core/legal-info: allow ignoring packages from the legal-info Yann E. MORIN
2015-12-13 18:35 ` [Buildroot] [PATCH 13/13 v2] core/pkg-virtual: ignore from legal-info output Yann E. MORIN

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=5672925A.5080400@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox