IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
It's all quite confusing having to reason about both the pre-composefs
ostree and the composefs version. But hopefully soon we more firmly
leave behind that first legacy.
Signed-off-by: Colin Walters <walters@verbum.org>
If composefs was explicitly requested (`enabled = true`) but libostree
was not compiled with composefs support, error out at deploy time. This
matches the logic in `ostree-prepare-root`.
The composefs libostree integration has been supported for a while now
and is actively in use in various ostree/bootc-based systems. Let's
turn it on by default.
This has no effect if composefs support is not compiled in. Note also
that this does not change the default value of the `composefs.enabled`
tristate to `true`. The default is still `maybe`, but the deploy API
will now also create composefs images for `maybe`.
The reason for doing it this way is so that systems upgrading from
old libostree versions (which may either not have composefs support or
may have composefs-related bugs) will still be able to upgrade and not
trip `ostree-prepare-root` in the new deployment (which allows missing
composefs images for `maybe`).
We may in the future change the default value to `true`.
See also: https://github.com/ostreedev/ostree/issues/2867
When recomputing selinux attrs during commit, we weren't sorting,
which could cause various issues like fsck failures.
This is a big hammer; change things so we always canonicalize
(i.e. sort) the incoming xattrs when creating a file header
and directory metadata.
I think almost all places in the code were already keeping
things sorted, but it's better to ensure correctness first.
If we ever have some performance issue (I'm doubtful) we
could add something like `_ostree_file_header_known_canonicalized`
or so.
Closes: https://github.com/ostreedev/ostree/issues/3343
Signed-off-by: Colin Walters <walters@verbum.org>
struct fsverity_digest starts with a __u16, so it will normally require
16-bit alignment, which is not guaranteed for a char array.
Resolves: https://github.com/ostreedev/ostree/issues/3339
Signed-off-by: Simon McVittie <smcv@debian.org>
