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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Before this commit, in the case where we have 3 deployments, the rollback code
would pick the merge/pending deployment. This is understandable since that logic
predates us potentially creating 3 deployments.
For livefs, I want rollback to actually go to the rollback, not the pending.
Add an API to find the pending/rollback, and put it in syscore, since we have
other similar functions to this there. (Perhaps in the future we'll figure out a
way to dedup the deployment walking/filtering logic a bit).
Port the two callers to it.
Closes: #767
Approved by: jlebon
While nothing else besides cleanup right now would call this directly, the code
should live close to the other very similar function:
`rpmostree_syscore_add_deployment()`.
Closes: #709
Approved by: jlebon
This is prep for livefs. We need to tweak the logic from what
core libostree has in `ostree_sysroot_simple_write_deployment()`,
and while we could land improved logic there, I think it makes
sense to carry this here until we're confident enough in the logic
to make it ABI.
This does depend on a [new libostree API](https://github.com/ostreedev/ostree/pull/745)
that allows writing deployments without doing cleanup.
The `bump_mtime()` bit is also prep for livefs, carrying in this patch to avoid
splitting things too much.
Closes: #709
Approved by: jlebon
Right now, the `rpm-ostree cleanup` logic calls into a "public static" method of
`RpmOstreeSysrootUpgrader`. That's because today, a lot of the high level "core
server side" logic lived in that class. However, it's only for upgrades (well,
really "generating pending deployments").
As I'm working on "livefs" which is really something different, I find it needs
to interact with some of `SysrootUpgrader`'s logic. Let's introduce a "sysroot
core" which is just a set of static functions taking an `OstreeSysroot*`, and
then all 3 of cleanup, (upgrade|deploy) and livefs can use these.
Closes: #708
Approved by: jlebon