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

[Yann E. MORIN]

Angelo, All,

On 2018-09-10 21:03 +0100, Angelo Compagnucci spake thusly:
> On Mon, Sep 10, 2018 at 8:44 PM Yann E. MORIN <yann.morin.1998 at free.fr> wrote:
> >     $ cat package/foo/Config.in
> >     config BR2_PACKAGE_FOO
> >         bool "foo"
> >         depends on !BR2_REPRODUCIBLE
> >         select SOME_PACKAGE
> >
> >     $ cat package/foo/foo.mk
> >     FOO_VERSION = 1.2.3
> >     FOO_DEPENDENCIES = some dependencies on other BR packages
> >     $(eval $(npm-package))
> >
> > and that the npm-package infra would do the call and install whatever
> > foo requires? Optionally, if the dependencies are already installed
> > (e.g. because of a FOO_DEPENDENCIES or another previous npm-package
> > already installed), then some dependencies may or may not be downloaded
> > by npm.
> 
> I'm not into this honestly. What I want to achieve is that a package
> can call a npm install or a glide install on whatever dependencies
> file the source code distributes. Without the need to open that file,
> understanding the dependency chain and reflect that in buildroot.
> 
> I think that the original developer knows better the dependencies of
> his software and we should trust the building infrastructure he
> choose, even more if what he choose is the best practice for that
> programming language.
> 
> Exactly As I did for the example I posted before.

And this is exactly what the npm-package (or glide-package, or whatever)
would end up doing: expand to FOO_BUILD_CMDS, FOO_INSTALL_CMDS et al.
that do the job, instead of repeating it in every package, like the
autotools-package infra allows to not repeat the .configure; make; make
install dance in all the autotools-based package.

For example, your watchtower would be writen as:

    WATCHTOWER_VERSION = v0.3.0
    WATCHTOWER_LICENSE = Apache-2.0
    WATCHTOWER_LICENSE_FILES = LICENSE.md
    $(eval $(glide-package))

And then the glide-pacakge infra would be defined sdmething like:

    define glide-pacakge-inner

    $(2)_DEPENDENCIES += host-glide

    define $(2)_GLIDE
        cd $$($(2)_SRC_PATH); GOPATH=$$($(@)_GOPATH) $$(HOST_DIR)/usr/bin/glide install
    endef
    $(2)_POST_CONFIIGURE_HOOKS += $(2)_GLIDE

    $(call golang-package,$(1),$(2),$(3),$(4))

    endef

Or something similar, like we do for the rebar-package infra, for
example, which piggy-backs onto either the generic-package or the
autotools-package infra as needed.

> > That would be fine by me.
> >
> > There is one gotcha though: this won't work for purely off-line builds.
> > This can be a big limitation in some setups, where access to an external
> > network is not always guaranteed, so we should carefully say so in the
> > manual.
> 
> Not true. A package can call the package manager in it's post download
> hook, so a make source should do an offline build without troubles.

But then said package manager would do only the download in the download
step?

I.e. I want to be able to do on 'somemachine' which has acces to both
the internal and external networks:

    $ export BR2_DL_DIR=/some/location
    $ make meh_defconfig
    $ make source
    $ scp -r /some/location someone at someserver:/somewhere

And on 'someserver' which does not have access to the network at all (by
a firewall that blocks out-going connections):

    $ export BR2_DL_DIR=/somewhere
    $ make meh_defconfig
    $ make

This is what I call an off-line build.

> Yes, if we can agree on a way to add package managers to buildroot!

I don't see any technical limitation to that, given the example you
provided.

Of course, I guess it is just a trivial example, and that real life is
little bit more tricky as usual, but there is nothing (besides my own
stubbornness, that is) standing in the road, is there?

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