A vmx image is the same disk as an oem just without the dracut
repart/resize feature. This difference is better handled with
an oemconfig parameter <oem-resize> which allows to switch resize
on or off. The extra image type vmx will be dropped and an XSLT
stylesheet automatically transforms a vmx description to be a
oem image with the resize feature switched off.
This Fixes#1425
This commit adds a documentation for the KIWI XML description.
In contrast to the former auto generated code from the XML
schema this document can now finally be used as a reference.
Along with that new chapter all auto generated and static
html content as been deleted. Also all helper scripts around
the proprietary oxygen tool and our schema doc generator
has been deleted. Auto generating this information does not
lead to a reference guide people can really work with.
As a consequence to these changes this commit also includes
some changes of the structure such that no information written
by other people in the past gets lost. This Fixes#1421
and Fixes#1474
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
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.
* Describe what KIWI needs to run, further requirements, and for development
* Introduce 'ghkiwi' as prefix in "extlinks" to shorten external links and
to make linking to KIWI's GitHub repository more intuitive and consistent.
For example, the string :ghkiwi:`tox.ini` is replaced with
https://github.com/SUSE/kiwi/blob/master/tox.ini
* Overall: try to be more consistent
* index.rst
* Move "Supported Distributions" and "Dropped Features" sections
* Quick Start:
* Add abstract
* Add note about automatic link creation
* Move "example appliance description" sections and subsections
further down
* Streamlined "Contributing" section
* Corrected titles and distinguish more between descriptive and
procedural
* Added Quick Start Guide, taken from README.md
* Improve index/main file:
* Shortend main entry page
* Make more headings
* Add feature highlights to draw attention
* Add sidebar with important KIWI links
* Use ordered list of KIWI concept (prep and creation step)
