A speciality of the rsync tool is that it behaves differently
if the given source_dir ends with a '/' or not. If it ends
with a slash the data structure below will be synced to the
target_dir. If it does not end with a slash the source_dir
and its contents are synced to the target_dir. For example:
source
└── some_data
1. $ rsync -a source target
target
└── source
└── some_data
2. $ rsync -a source/ target
target
└── some_data
The parameter force_trailing_slash in the DataSync::sync_data
method can be used to make sure rsync behaves like shown in
the second case. This Fixes#1786
Moving use of mkdtemp, NamedTemporaryFile and TemporaryDirectory
into its own class called Temporary: By default all temporary
data is created below /var/tmp but can be changed via the
global commandline option --temp-dir. This Fixes#1870
If the Codec.decode() method cannot encode the given data to utf-8
an Encoding exception is raised which causes kiwi to raise a
KiwiDecodingError. That way to handle the error causes an image
build to fail. However, this sort of error for example happens if
the .changes file of a package contains invalid characters. From
a user perspective this cannot be fixed and you cannot build the
image because of a stupid character error in a .changes file
outside your control. Because of this reason this commit handles
the decode error case differently and applies the 'replace'
strategy on error. The characters in questions gets replaced and
the rest of the data which can be decoded is returned.
The new attribute <volume ... filesystem_check="true|false"/>
allows to change the default value for the fs_passno field in
the generated fstab file. By default kiwi sets "0" in this
field and leaves it up to the user to customize this as
appropriate via script code. Coding changes to the fstab file
via scripts are not very user friendly and with respect that
systemd takes over control and generates checkers depending on
the value of fs_passno it would be good if there is a way to
explicitly specify if checks to the filesystem are wanted or
not. Therefore the new attribute now exists. If set to: true
this results in a value of "2" for the fs_passno field. Please
note the root/boot and efi entries are excluded from this
setup. This Fixes#1728
If devicepersistency="by-label" is set in the KIWI description
it will correctly operate on the fstab values but still uses
the UUID based setting for root= in the grub config. This commit
allows to set root=LABEL=... in the grub config in case the
devicepersistency requested it. In order for this to work this
commit also had to increase the scope of the grub helper
method _fix_grub_root_device_reference which is now called in
any case. This Fixes#1757
Allow to read multiple markup formats. Supported are XML
and YAML. The parsing and transformation is based on the
anymarkup module. The use of anymarkup is optional and
implemented as an on demand loading module. If a user
uses a yaml config file or a request to convert into
yaml is made without an installed anymarkup module an
exception is thrown
This commit ensures that when trying to parse the version of a tool
the comparison is done with the longest match for the given regular
expression. This solves cases such in `grub2` where the tool name
already provides some digit that could be seen as a version.
With the new Fstab class from prior pull request there is an
opportunity to handle all fstab related actions to be done
by that class. This commit extends the Fstab class with an
add_entry method such that we can avoid the extra lists
holding raw fstab lines in e.g the disk builder. In the end
all fstab related data is stored in an instance of the Fstab
class. This also extends the KIWI api by an fstab management
class. Related to #1329 and #1349
Handling of fstab should be done in its own namespace and class.
The current handling of fstab entries is spread at several places.
There should be only one code that writes the fstab entries and
that code should also care for the correct canonical order of
the mountpoints
This commit refactors the use of Path.which in several parts of the
code. Since dd4d2ed78 the Path utility is capable to run Path.which
on certain chroot env, thus no need to adapt the PATH environment
variable.
Fixes#1281