There is the legacy kiwi version and there is this kiwi(next generation).
From a documentation perspective there are several inconsistencies that
could confuse users. This commit makes the name for KIWI-NG consistent
across the entire documentation. At places where we point to older
documentation we use the term Legacy KIWI and a link to the documentation
that covers this part. All this is needed in preparation to cleanup the
documentation situation for the SUSE documentation but with respect to
the upstream doc sources, their layout and markup.
SUSE documentation is based on docbook or asciidoc. The kiwi
documentation is maintained along with the code and uses the
sphinx system and therefore ReST as markup language. We would
like to keep one source and don't want to move to another markup
language. Thus the sources needs to be structured in a way that
allows translation into sphinx supported targets as well as
into SUSE docbook style. This commit changes the documentation
structure in a way that both is possible. With the use of Sphinx
XML and rstxml2docbook the ReST docs are converted into docbook.
From there the SUSE daps tool can create SUSE documentation
There is no further demand in the client config creation for the
legacy netboot code. Customers using the netboot initrd already
create the client config.<MAC> file manually or through another
system. With the next generation kiwi we also recommend the disk
based network deployment using the dracut capabilities and marked
the netboot code as still supported but on the legacy stream.
Along with the deletion in the schema the following changes
were also done:
* Deleted use of pxedeploy section in implementation
* Increase schema version to v7.0
* Update documentation on schema version update
* Added xsl stylesheet conversion from v6.9 to v7.0
Automatic schema version upgrade from v6.9 to v7.0 deletes
the pxedeploy section from any type specification
This Fixes#19
In reference to Refactor OCI images packing the difference
between docker and OCI images is just on packing format.
Thus the extra docker container subclass is no longer present.
This commits adds initial support to build Vagrant boxes with the Virtualbox
provider.
- The attribute 'provider' of the option <vagrantconfig> now supports the option
"virtualbox".
- A new boolean attribute 'virtualbox_guest_additions_present' was added to
<vagrantconfig>. When set to true, KIWI will assume that guest additions have
been installed into the base image and configure the shared folders to use
vboxfs, otherwise rsync will be used.
This fixes#532 (https://github.com/SUSE/kiwi/issues/532).
YUM v3 is no longer developed, having been superseded by DNF for
several years. With DNF now available as a usable package manager
in Red Hat Enterprise Linux 7 through the Extras channel and
SUSE Linux Enterprise 15 through PackageHub, there is no reason for
keeping support for YUM v3 around.
We are keeping support for requesting YUM because in Red Hat Enterprise
Linux 7, DNF is referred to as "YUM v4", and it is simply referred to
as "YUM" in Red Hat Enterprise Linux 8. To avoid confusion from people,
we're just going to leave it in place as an alias to the DNF package
manager.
As for why this is happening now, Fedora is retiring YUM v3 in
Fedora 31, so we might as well get it over with and cut over now.
Reference: https://fedoraproject.org/wiki/Changes/Retire_YUM_3
In preparation to support other vagrant providers a base class
for Vagrant operations has been created. Original Code written
by DanČermák <dcermak@suse.com>
This commit adds imageonly attribute support for the repository
element. imageonly is a boolean attribute that if true indicates
that the repository is no used for the build but needs to be
configured for the resulting image.
Fixes#362
This commit adds repository_gpgcheck and package_gpgcheck attributes
to the repository tag in schema. With this change each repository
can be configured individualy to enable repository signatures check
and/or enable signature package check. The configuration is done at
repository level, thus it is not conflicting with the wide package
manager configuration flag <rpm-signatures-check>.
Fixes#358
The current design of the documentation does not allow for
continous improvement and development. It's missing a basic
structure and concept for documenting step-by-step workflows
and generic explanations.
