diskimage-builder/diskimage_builder/elements/package-installs
Ian Wienand f068e6aa6e Fix package-installs-v2 output
The current output for package-installs-v2 is inscrutable [1]

The problem starts with process_output() which is not capturing
stderr.  This means that any stderr output is dislocated from any
stdout output around it.  This is *really* confusing as you get a
bunch of seemingly meaningless stderr output from any calls before you
see any stdout (e.g. in [1] you can see random yum error output that
should have been with the yum call)).  The simplest thing to do is to
redirect stderr to stdout which keeps everything in sync.

This causes a slight problem, however, because pkg-map outputs both
status information and errors on stderr.  To work around this but
maintain compatibility, we add a "--prefix" argument that prepends
mapped packages from pkg-map with a value we can match on.  The
existing status/debug output from pkg-map is low-value; modify the
call so that it will be traced only at higher debug levels (e.g. -x
-x).

The current loop is also calling pkg-map for every package in every
element (this is why in [1] the same message is repeated over and
over).  This is unnecessary; it only needs to pkg-map once for each
element, giving the package list as the arguments.  Create package
lists by element and pass those to pkg-map.

As a cleanup, there is no point in printing e.output if the
process_output fails for the install because we are already tracing
it; i.e. the output, even for failures, is already in the logs.
Printing it again just duplicates the output.

[2] is an extract showing what I feel is a much more understandable
log output for a fairly complex install.

[1] http://paste.openstack.org/show/595118/
[2] http://paste.openstack.org/show/595303/

Change-Id: Ia74602a5d2db032a476481caec0e45dab013d54f
2017-04-07 13:48:53 +10:00
..
bin Fix package-installs-v2 output 2017-04-07 13:48:53 +10:00
extra-data.d squash-package-install to use the correct python 2017-03-13 20:24:39 +11:00
install.d Move elements & lib relative to diskimage_builder package 2016-11-01 17:27:41 -07:00
post-install.d Move elements & lib relative to diskimage_builder package 2016-11-01 17:27:41 -07:00
pre-install.d Move elements & lib relative to diskimage_builder package 2016-11-01 17:27:41 -07:00
element-deps Move elements & lib relative to diskimage_builder package 2016-11-01 17:27:41 -07:00
README.rst Release 1.25.2 2017-02-02 11:20:00 +11:00

================
package-installs
================

The package-installs element allows for a declarative method of installing and
uninstalling packages for an image build. This is done by creating a
package-installs.yaml or package-installs.json file in the element directory.

In order to work on Gentoo hosts you will need to manually install
`dev-python/pyyaml`.

example ``package-installs.yaml``

.. code-block:: YAML

  libxml2:
  grub2:
    phase: pre-install.d
  networkmanager:
    uninstall: True
  os-collect-config:
    installtype: source
  linux-image-amd64:
    arch: amd64
  dmidecode:
    not-arch: ppc64, ppc64le
  lshw:
    arch: ppc64, ppc64le
  python-dev:
    dib_python_version: 2
  python3-dev:
    dib_python_version: 3

example package-installs.json

.. code-block:: json

    {
    "libxml2": null,
    "grub2": {"phase": "pre-install.d"},
    "networkmanager": {"uninstall": true}
    "os-collect-config": {"installtype": "source"}
    }


Setting phase, uninstall, or installtype properties for a package overrides
the following default values::

    phase: install.d
    uninstall: False
    installtype: * (Install package for all installtypes)
    arch: * (Install package for all architectures)
    dib_python_version: (2 or 3 depending on DIB_PYTHON_VERSION, see dib-python)

Setting the installtype property causes the package only to be installed if
the specified installtype would be used for the element. See the
diskimage-builder docs for more information on installtypes.

The ``arch`` property is a comma-separated list of architectures to
install for.  The ``not-arch`` is a comma-separated list of
architectures the package should be excluded from.  Either ``arch`` or
``not-arch`` can be given for one package - not both.  See
documentation about the ARCH variable for more information.

DEPRECATED: Adding a file under your elements pre-install.d, install.d, or
post-install.d directories called package-installs-<element-name> will cause
the list of packages in that file to be installed at the beginning of the
respective phase.  If the package name in the file starts with a "-", then
that package will be removed at the end of the install.d phase.

Using post-install.d for cleanup
================================

Package removal is done in post-install.d at level 95.  If you a
running cleanup functions before this, you need to be careful not
to clean out any temporary files relied upon by this element.
For this reason, generally post-install cleanup functions should
occupy the higher levels between 96 and 99.