A merging strategy

[schaefi]

When building based on a stash image there are two image descriptions:

• The one in the stash
• The one provided in stackbuild

In the current implementation the stackbuild provided image description takes precedence
over the one in the stash. It will simply be overwritten.

This means the stackbuild provided image description must be a full description even though
parts of it are already described in the used stash image.

From there the idea of a merging strategy was discussed and @davidcassany had the following
idea:

@davidcassany: approach on merging strategy

My approach was to define a new schema (based on the artifacts of the current one, so no redefinition of elements) that is less restrictive (does not require description, neither preferences and does not consider profiles). This schema purpose would only be to define descriptions that are not complete, they are only meant to be merged on top of a real valid schema. In fact, the stashed image could be a required attribute of element. So the idea is that the plugin parses using this new type of schema, collects data and applies the data into real fully valid schema found inside the image. Some thing like an structured way of modifying an XMLState instance.

My idea was pretty simple, forget about profiles and distinguish elements by two categories: (i) drop-in elements, (ii) mergeable. And only care about top level elements. For instance is a drop-in element, the merging strategy for them is dumb, I just add the whole section as there were multiple sections. Then, would be a mergeable section, so that requires specific logic to define what merging means. I got up to the conclusion only preferences and description sections are mergeable and also thought that by removing profiles from the picture turns the idea of merging some into something doable. I did not consider going deeper in the three, so no specfic logic merging , keep the stashed one or replace with a new provided one.

My idea was to allow XMLs that could look like:

<image stashed="opensuse/jeos-live" name="appliance_on_top_of_jeos">
  <packages type="image"> <!-- This would be computed as a full new packages section added in the stashed XML -->
     <!-- a list of additional packages -->
  </packages>
</image>

or

<image stashed="opensuse/jeos-live">
   <preferences>
      <!-- This results into a replacement of the whole built `<type>`-->
      <type image="iso"....> <!-- some different type section -->
   </preferences>
</image>

So all of these I think it is reasonable as long as one considers:

• the XML is not a KIWI compliant XML, it is mapped against a new schema that is slightly different compared the original.

• the stashed XML is already profiled (it does not include profiles, it is the actual digested XML used for the build)

• the merging strategy is simple and only up to top level elements and it always results into a full KIWI XML that is validated against the KIWI schema.

[schaefi]

This references the conversation in #1