Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 05/16 v5] core/legal-info: ensure legal-info works in off-line mode
Date: Sat, 19 Mar 2016 19:18:10 +0100	[thread overview]
Message-ID: <20160319181810.GC3426@free.fr> (raw)
In-Reply-To: <20160319154741.750d2bbd@free-electrons.com>

Thomas, All,

On 2016-03-19 15:47 +0100, Thomas Petazzoni spake thusly:
> On Fri, 11 Mar 2016 18:49:18 +0100, Yann E. MORIN wrote:
> > Almost all packages which are saved for legal-info have their source
> > archives downloaded as part of 'make source', which makes an off-line
> > build completely possible [0].
> > 
> > However, for the pre-configured external toolchains, the source tarball
> > is different, as the main tarball is a binary package. And that source
> > tarball is only downloaded during the legal-info phase, which makes it
> > inconvenient for full off-line builds.
> > 
> > We fix that by adding a new rule, $(1)-legal-source which only
> > $(1)-all-source depends on, so that we only download it for a top-level
> > 'make source', not as part of the standard download mechanism (i.e. only
> > what is really needed to build).
> > 
> > This new rule depends, like the normal download mechanism, on a stamp
> > file, so that we do not emit a spurious hash-check message on successive
> > runs of 'make source'.
> > 
> > This way, we can do a complete [0] off-line build and are still able to
> > generate legal-info, while at the same time we do not incur any download
> > overhead during a simple build.
> 
> I am wondering what is the motivation for making "make legal-info"
> absolutely executable off-line, after a "make source".

I think you (sort of) got it backwards.

The reason is not about doing "make source; make legal-info", but to be
able to do "make source" and store all in a local mirror for example.

Companies like not to rely on third-party /storage/ and want to mirror
the whole world, just in case (and that's sane; one can not rely on a
third party for legal stuff, especially one that is not sub-contracted
to that effect, like most FLOSS projects are).

So, really, the case for "make source" to also retrieve the actual
sources is about being able to not rely on the upstream for legal-info.

> I was about to
> apply this patch, so my opinion is definitely not firm on this, but
> I have some concern:
> 
>  * Now "make source" is downloading more stuff than is actually needed
>    to do the build. And potentially a *lot* more this is going to
>    download the source code for the toolchain, which you absolutely
>    don't care about. So for a CodeSoucery ARM toolchain, instead of
>    download just the 97 MB of the toolchain, you would download 97 MB +
>    278 MB of source code. You're basically quadrupling the data to be
>    downloaded for the toolchain itself.

Yes, this is unfortunate when one is not interested in legal compliance
(e.g. for a purely internal use without redistribution).

>  * Now, after a successful build, "make source" will no longer be a
>    no-op operation, because "make source" will also download the files
>    needed for legal-info. This is IMO rather unexpected.

I see. This can indeed be seen as unexpected.

However, I was pondering another change, whereby the build would
*always* trigger legal-info. I am absolutely not sure about that one,
but I like that "make" generates *all* output artifacts, of which I
consider legal-info to be part. But this is for another day, if ever...

> Now whether those two concerns are really sufficient to justify a
> different implementation can be discussed. One possible solution is to
> have a "make legal-info-source", which would download whatever
> legal-info needs to be executed offline.

I'm not so sure. One interesting point in hooking into "make source" is
that everyine already knows about it. I am not too fond of adding yet
another top-level make target...

But if that would allow for the merging of that series faster, I'd be OK
with that.

> That being said, we're really talking about a few corner cases, because
> essentially, only the external toolchains currently make use of
> <pkg>_ACTUAL_SOURCE.

And when the user has a local download directory outside of Buildroot,
it acts as a cache, and it will be doewnloaded only once.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2016-03-19 18:18 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 [this message]
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
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=20160319181810.GC3426@free.fr \
    --to=yann.morin.1998@free.fr \
    --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