[Buildroot] [PATCH v5 0/3] Add tainting support to buildroot
Yann E. MORIN
yann.morin.1998 at free.fr
Sun Sep 9 13:33:41 UTC 2018
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 at 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. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list