Make repo locking API public #2286
Comments
|
Yeah, I think exposing the APIs makes sense. |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Apr 15, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Apr 15, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to dbnicholson/ostree
that referenced
this issue
Apr 29, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to dbnicholson/ostree
that referenced
this issue
Jun 5, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev#2337 Closes: ostreedev#2286
dbnicholson
pushed a commit
to endlessm/ostree
that referenced
this issue
Jun 7, 2021
Doing anything even somewhat sophisticated requires this; turns out our own `ostree prune` CLI wants this, e.g. ostreedev/ostree#2337 Closes: ostreedev/ostree#2286 (cherry picked from commit 0f36d8c) The new symbols have been added to the released symbols file rather than the development symbols file as in the upstream PR since our package does a released build. Similarly, the upstream `LIBOSTREE_2021.3` symbol version has been used so that packages don't need to be rebuilt when we get to that version and drop our backported commits. https://phabricator.endlessm.com/T31868
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Back in #1292 and temporarily in it's slimmer cousin #1555 the repo locking APIs were public. I think it would be useful to have the API public, particularly for cases when you're going to do repo maintenance and want to ensure no one else is modifying the repo. On our Endless ostree server I've wanted this many times for doing unusual operations on repos to the point that I basically copied the whole locking scheme into python and our tooling relies on that to work.
Now we have a use case similar to https://raw.githubusercontent.com/endlessm/eos-meta/master/eos-tech-support/eos-fix-ostree-repo where we want to make dangerous changes on client repos. In particular, we want to undo the dubious decision we made many years ago to have flatpak use
/ostree/repoas its repo. In order to split these up reliably we really want to make sure none of our various ostree programs (gnome-software and eos-updater primarily) can alter the repo while the surgery is happening.Anyways, I think the locking has proven to be robust, although I do share your concern about deadlocking when there are multiple threads in play. I don't know what to do about it besides tell apps to be careful with exclusive locks, though.
What do you think?
The text was updated successfully, but these errors were encountered: