[Buildroot] [PATCH v5 0/3] Add tainting support to buildroot
Yann E. MORIN
yann.morin.1998 at free.fr
Mon Sep 10 15:00:09 UTC 2018
Angelo, All,
On 2018-09-10 09:50 +0200, Angelo Compagnucci spake thusly:
> > Last one, I promise!
[--SNIP--]
> I just pushed o POC on my local branch if you want to have a look.
> It's what I mean for tainting applied to a package with a more robust
> ad correct approach that the npm case:
> https://github.com/angeloc/buildroot/commits/watchtower
So, here is my last stance on the subject, in which I tried to summarise
my position.
Why would the "tainted" flag be set?
- unknown licensing information: it is better to use the existing
licensing infrastructure, which is made for this very purpose:
FOO_LICENSE := $(FOO_LICENSE), Unknown (external data used)
- non-reproducible packages in Buildroot: I don't think we should
accept packages in Buildroot that would taint the build; and if we
were, we could hide them behind !BR2_REPRODUCIBLE (with or without
a comment stating "foo is not reproducible");
- packages that are in a br2-external, or in a private fork: I believe
that people who do non-reproducible packages either don't care,
have no choice, or both. If they did care, they would not create
tainting packages; if they did care but still had no choice, they
could also decide to hide them behind !BR2_REPRODUCIBLE;
- packages with a list of external resources, like we have for
nodejs/npm: we can't know if that list references reproducible
resources or not.
That last point is very important: there *are* people that do care about
the reproduciblity of a build, and thus have already taken care that
BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL *does* point to stable and
reproducible set of nodejs modules [0]. Patch 3 in the series would mark
for them that the build is tainted when it is not; since those people do
care, the tainted flag would be most important to them, but by always
marking their build as tainted, the flag becomes useless to the very
people that do care...
Yes, a lot of people will just use a non-stable list, and they even
probably do not care either. I do not want to have to impose that
limitation unto those who know what they are doing.
So, I still conclude that we do not need to have a tainted flag.
[0] For example, consider an explicit and complete list such as (spitted
for readability):
BR2_PACKAGE_NODEJS_MODULES_ADDITIONAL="
http://internal-server/node/mod-1
http://internal-server/node/mod-2
http://internal-server/node/mod-3
http://internal-server/node/mod-4
"
and that all the dependencies of those modules *are* present in that
list, leaving npm no chance to download anything.
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