Adding support for a new Stackbuild specific schema

[davidcassany]

This is adding a new schema type for stackbuild plugin on build commands. Descriptions provided by the --description flag are parsed to check if they include the stackbuild attribute at root level, if not it assumes this should be validated as a regular KIWI description, however if the staclbuild="true" attribute is there the description is validated against the new schema.

The new schema is essentially the same as a regular KIWI description with the difference that any section under <image> is optional. Stackbuild schema can only be used against stashed images, which implies the stashed image already includes the KIWI description used at stash time. This new stackbuild schema is essentially used to replace or add sections to the stashed description. At build time the stackbuild description is applied on top of the stashed KIWI description to create a new full KIWI description. Then the build proceeds as a regular KIWI build (including XML validation).

This is useful to apply small modifications over an existing image without having to duplicate the whole description. Imagine adding extra packages, provide a new <type>, include extra users, etc. All other files of the description (e.g. config.sh) are rsynced on top of the stashed description. Hence the original is preserved or replaced, new ones could also be included this way.

[davidcassany]

With this change I could something like the following.

Based on the tumbleweed description form the examples repository. I did the following steps:

# Preare the root-tree of the system
sudo kiwi-ng --debug system prepare \
        --description kiwi-descriptions/suse/x86_64/suse-tumbleweed --root root-to-stash
        
# Stash the prepared system
sudo kiwi-ng system stash --root root-to-stash --container-name tw-stash

# Build the stashed image with a new stackbuild description to include additional packages and modify OEM type
sudo kiwi-ng --type oem system stackbuild --stash tw-stash --target-dir new-tw-build --description demo

Where the contents of the demo folder is just a stackbuild XML description:

<?xml version="1.0" encoding="utf-8"?>

<image schemaversion="0.1" stackbuild="true" name="tumbleweed">
    <description type="system">
        <author>Marcus Schaefer</author>
        <contact>[email protected]</contact>
        <specification>
            Tumbleweed Appliance, is a small text based image including podman container runtime
        </specification>
    </description>
    <preferences>
        <type image="oem" filesystem="xfs">
            <oemconfig>
                <oem-systemsize>4096</oem-systemsize>
            </oemconfig>
        </type>
    </preferences>
    <packages type="image">
        <package name="podman"/>
    </packages>
    <packages type="oem">
        <package name="dracut-kiwi-oem-repart"/>
    </packages>
</image>

The description only includes a new podman package and dracut-kiwi-oem-repart package in case of building an oem type. In addition the oem type has been replaced by a new one requiring the kiwi-repart dracut module. Any other package type, image type still remain as they were. Hence from the given description running something like:

sudo kiwi-ng --type oem system stackbuild --stash tw-stash --target-dir new-tw-build --description demo

is still valid and results into an ISO from the stashed content including the podman package.

[davidcassany]

This PR is just to somehow finalize what I attempted to do back in a day when I started thinking around this plugin back in 2021 during a Hackweek. The xml_merge class was already coded in my local environment since then, but, at a time, I did not manage to get it fully integrated with a proper schema validation, unit testing and all that.

This might be still a rough implementation but, IMHO, good enough to be discussed, tested and eventually polished if needed without having to rework it that much.

[davidcassany]

This is the logic that I could not manage to figure out at a time, how to include the KIWI schema file during validation being sure the schema I am including is the one that will be actually in use by currently loaded module (there could be more than one KIWI installation around), so basically it is not an option to hardcode any path in the schema.rnc as I could not figure out a relative path that works for RPM installation, pip install, virtualenvs, etc.
The work around is to dynamically set the KIWI schema path at run time with the Defaults.get_schema_file method. Then use a dummy fake schema to run the convertion from rnc to rng, because trang also converts and parses any included file...