All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [RFC] [PATCH v2 2/2] support/kconfig: Bump to kconfig from Linux 4.17-rc2
Date: Tue, 29 May 2018 19:04:29 +0200	[thread overview]
Message-ID: <20180529170429.GM2965@scaer> (raw)
In-Reply-To: <67a166b0-1466-8bd9-86be-3a8f3d7a4079@mind.be>

On 2018-05-29 12:44 +0200, Arnout Vandecappelle spake thusly:
> On 28-05-18 22:37, Yann E. MORIN wrote:
> > Arnout, Thomas, All,
> > 
> > On 2018-05-22 23:22 +0200, Arnout Vandecappelle spake thusly:
> >> On 20-05-18 16:50, Thomas Petazzoni wrote:
> [snip]
> >>> If we start relying on the system-installed flex and bison, then we
> >>> should remove host-flex and host-bison entirely, not only for the linux
> >>> package. The question is whether bison and flex both behave in a
> >>> reasonably similar way regardless of which version is used.
> >>
> >>  I briefly looked at this in Paris, and it became clear very quickly that even a
> >> minor change in the bison version would give a completely different .c file. If
> >> this is a source file that will be built for the target, it's going to be a
> >> major reproducibility-killer. So I don't think we can remove host-bison and
> >> host-flex.
> > 
> > We're only talking about dropping the need for host-flex and host-bison
> > for the kconfig stuff. In this case, we don;t care that the user
> > generates C code one way or another: it's only a host tool...
> 
>  I was replying to Thomas's "we should remove host-flex and host-bison
> entirely". Yes we can rely on system-installed flex and bison for kconfig, but
> we can't rely on that for target packages, e.g. target dtc.

Mostly agreed. Like, 99.9%.

There are two concerns. Reproducibility and compliance.

IANAL, but the second can be achieved given a specific environment. So,
if one would state "build done on distro Foo version Bleh, with this
C&CS", this is probably enough for compliance. But IANAL.

The first is more interesting. Again, if the build is attmpted a second
time if the same envirnment, then this is reproducible, and probably
good enough for an industrial context (where official builds for
production are hopefully done in a controlled environment, not on a
random machine of a random developper).

In both cases, we would not really care to depend on the distro-provided
flex and bison, as long as said distro is properly identified.

Now, if we talk about reproducibility on any host for verifiability, then
we indeed absolutely want to keep them. Verifiability also helps with
compliance anyway.

And finally, there is a third reason that may be interesting to consider:
bugs in flex or bison, or change of API. I am not aware of such issue,
though...

So, in the end, I agree with you that we want to keep our host variants,
because it at least helps us for verifiable reproducibility.

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:[~2018-05-29 17:04 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 16:44 [Buildroot] [PATCH v2 1/2] support/kconfig: Add missing target to README.buildroot Petr Vorel
2018-05-09 16:44 ` [Buildroot] [RFC] [PATCH v2 2/2] support/kconfig: Bump to kconfig from Linux 4.17-rc2 Petr Vorel
2018-05-19 21:03   ` Thomas Petazzoni
2018-05-20  5:05     ` Petr Vorel
2018-05-20 14:23     ` Yann E. MORIN
2018-05-20 14:31       ` Petr Vorel
2018-05-20 14:41         ` Yann E. MORIN
2018-05-20 14:50           ` Thomas Petazzoni
2018-05-22 21:22             ` Arnout Vandecappelle
2018-05-28 20:37               ` Yann E. MORIN
2018-05-29 10:44                 ` Arnout Vandecappelle
2018-05-29 17:04                   ` Yann E. MORIN [this message]
2018-07-30 13:04                   ` Thomas Petazzoni
2018-07-31  7:55                     ` Arnout Vandecappelle
2018-07-31  8:06                       ` Thomas Petazzoni
2018-07-31  8:20                         ` Arnout Vandecappelle
2018-08-01 19:42                           ` Yann E. MORIN
2018-08-01 20:20                             ` Yann E. MORIN
2018-08-02 11:02                             ` Arnout Vandecappelle
2018-08-02 17:10                               ` Yann E. MORIN
2018-08-03 16:24                                 ` Yann E. MORIN
2018-05-09 16:46 ` [Buildroot] [PATCH v2 1/2] support/kconfig: Add missing target to README.buildroot Petr Vorel
2018-05-13 20:09 ` Thomas Petazzoni

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=20180529170429.GM2965@scaer \
    --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 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.