[Fuego] [PATCH 2/9] Refactor preinst and apt-get/pip install

[Tim.Bird at sony.com]

> -----Original Message-----
> From: Gustavo Sverzut 
> 
> On Tue, Jan 30, 2018 at 5:22 PM,  <Tim.Bird at sony.com> wrote:
> >> -----Original Message-----
> >> From: Guilherme Campos Camargo
> >> All base-image related apt-get commands (including pre-install config,
> >> as well as the package install) have been put together in the same RUN
> >> instruction.
> >>
> >> The same has been done with the LAVA-related apt-get commands on
> this
> > Do you mean Fuego-related?
> >
> >> patch. They can't be merged because the requirements are using a
> >> specific key that needs to be downloaded with curl (that's installed in
> >> the previous step. Additionally, LAVA apt-get commands have been
> moved
> > Another reference to LAVA?
> 
> ops, and I missed those in my review as well.

No problem.  It's not like people look at commit messages a lot after
the review ;-)

> 
> ...
> >> apt-get update && \
> >> +    apt-get -yV install \
> >> +        apt-utils \
> >> +        at \
> >> +        autoconf \
> >> +        automake \
> >> +        bc \
> >> +        bsdmainutils \
> >> +        bzip2 \
> >> +        cmake \
> >> +        curl \
> >> +        daemon \
> >> +        diffstat \
> >> +        g++ \
> >> +        gcc \
> >> +        gettext \
> >> +        git \
> >> +        inotify-tools \
> >> +        iperf \
> >> +        lava-tool \
> >> +        libaio-dev \
> >> +        libcairo2-dev \
> >> +        libglib2.0-dev \
> >> +        libsdl1.2-dev \
> >> +        libtool \
> >> +        libxmu-dev \
> >> +        libxmuu-dev \
> > Most of the above libs are also toolchain packages, for x86_64 (the docker
> virtual board)
> > and would benefit from being moved to a separate image creation step or
> derivative
> > image.
> 
> you mean those *-dev, cmake, autoconf, automake, gcc, g++, gettext and
> libtool? indeed makes sense to move these to separate image once we
> split the armhf.

Just the lib*-dev.  and gcc and g++.  cmake, autoconf, automake and libtool
are non-architecture-specific parts of the toolchain, which would be used
by any SDK used in the container, I believe.  I'm not sure about gettext.
I think it provides libraries or headers that would get compiled into binaries
that go to the target, so likely it is x86_64-specific. 

The only things that Fuego intends to compile (right now), are things for the
target boards.  That's not an absolute hard and fast rule.  I could imagine
some test program having both a host-side and target-side component
that needed to be compiled.  But I don't think we have any of those at the
moment.  ... (I just checked the Functional.commonAPI_* tests, which I
thought might have both host and target compiled programs, but they
apparently don't.  So I'm pretty sure this is correct.)

In any event, the general rule would be that the SDK installation step
should have the packages needed for compilation of programs intended
to run on the target.  docker is a special target, and we default
to including the SDK for that included in the base image.  But it would
still be good to keep these in a separate list.
 -- Tim