[Buildroot] [PATCH v5 0/3] Add tainting support to buildroot

[Yann E. MORIN <yann.morin.1998@free.fr>]

Angelo, Thomas, All,

On 2018-09-09 13:25 +0100, Angelo Compagnucci spake thusly:
> On Sun, Sep 9, 2018 at 1:10 PM Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> wrote:
[--SNIP--]
> Thomas said evrithing exceptionally well, but I would like to
> underling another thing: automated building infrastructures like
> continuos integration.
> 
> If a project hasa nedd of reproducibility, the countinous integration
> could check if a random developer introduced something not
> reproducible and mark the build as invalid. I think this is really a
> big plus of this solution.

I do understand the concern, trust me, I do.

What I am saying is that the solution you propose will not allow that,
because there is no way to decide whether a specific .config is or is
not reproducible, as per the examples I provided in the nodejs case.

If a build is imprperly marked as tainted, then users will just
disregard that information and never consult it, and just not use it in
their automated buildsystemsd (jenkins, gitlab-ci, whatever). And even
if they do have a job doing the check, that job can detect a change from
"not tainted" to "tainted" because the job will always report "tainted".

So, your solution does not even cover your automated builds use-case
either.

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.  |
'------------------------------^-------^------------------^--------------------'