Allow to validate the return code from a package manager
operation. In case of zypper the standard UNIX return
code validation does not apply. Return codes from zypper
which are >= 100 are not treated as an error anymore
The location of the rpm database is no longer a standard
path one can trust. Some distributions put it to /var/lib
others to /usr/lib. This introduces the problem of dealing
with different locations between the bootstrapping (host rpm)
phase and the image installation (image rpm) phase.
This commit implements a solution based on an intermediate
rpm database configuration. KIWI creates the macros.kiwi file
inside of the image root which is read by any call of rpm
in the inner and outer system. During bootstrap phase the
rpm dbpath from the host system is used and later in the
install phase the dbpath from the rpm package as it was
installed by the target image distribution is used. In case
of a dbpath difference the database is automatically moved
to the new location by setting the _dbpath_rebuild macro
to the correct location. At the end the custom KIWI macro
is deleted.
As this process allows custom macro defintions during the
KIWI run it also serves as the base for a solution to
Issue #771 which will be done in a follow up request to
this commit.
Also the workaround for bsc#1112357 which uses a static
dbpath to store an optionally given signing key will be
addressed with this commit. The macro setup happens before
the import_trusted_keys method which makes any specification
for a strict dbpath obsolete.
Last the implementation deletes the obsolete
dump_reload_package_database code. rpm is able to automatically
do the conversion of different db versions such that the code
in kiwi is obsolete. In addition that code only worked for
rather old db versions. The public API has not changed though,
but the method is marked obsolete and does nothing anymore.
In addition to the deletion of obsolete code a new API
method post_process_install_requests_bootstrap has been
introduced to handle actions required after bootstrap
and before installing of packages from inside the new image
With this commit package manager are always set to include only
required packages or set to include required and recommended
packages.
This commit fixes#285
The request_package_lock was renamed into request_package_exclusion
because that is the goal, to actually exclude(skip) a package. From
an implementation point of view this is done to set a lock in the
zypper case. However other package managers might do it differently.
The interface should stay consistent with regards to the user goal
and not with the package manager specific implementation. This
Fixes#248
Zypper supports the al (add lock) command which allows to ignore
a package in the dependecny resolution process. This is useful
to prevent installation of a package which was pulled in by e.g
a recommendation flag from the spec file. Packages marked to be
ignored are not handled for apt and yum right now. Using this
feature together with an unsupported package manager backend
results in a warning to the user
nose is no longer maintained, thus we have to move to another
testing system. This commit updates the tox setup and all tests
to use pytest instead of nose.
