Versioning based on btrfs snapshots
Description
I actually like the bottles application for managing wine prefixes. However it itches me, that I can not create the bottles as btrfs subvolumes, which I want to use it with my backup solution, to backup/restore bottles independently. I also tried to create the subvolume in place before creating a bottle, but bottles is appending a random number to the path, if the bottle directory already exists. This motivates the commits up to fc7513ac541fb3e93b1f3fa23101201084b2a35d.
I went a bit over the top and implemented it further, until I can create and restore bottle snapshots using the bottles GUI. With all updates added to this PR, I think this is ready to be merged.
Any feedback is appreciated.
Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [x] This change requires a documentation update
How Has This Been Tested?
- [x] btrfsutil's calls work also inside flatpak's sandbox
- [x] Bottles are created as btrfs subvolumes, if the filesystem is btrfs.
- [x] Creating snapshots and resetting to them using btrfs snapshots.
- [x] All snapshots have meaningful timestamps
- [x] The "active" state is marked
- [x] Duplicated bottles are created as subvolumes. This can be used to "import" existing bottles into btrfs snapshot based versioning
- [x] Duplicated bottle, where the source bottle is a subvolume, is created as a lightweight snapshot bottle
- [x] Deleting a bottle, deletes the associated btrfs snapshots
- [x] If the bottle is not a subvolume or has pre-created FVS states, it falls back to the FVS system. (I encountered a critical bug #3416, which affects the release version, too)
- [ ] TODO regression testing on non btrfs filesystem. (Help would be appreciated)
I have updated the PR today:
Does this work within a flatpak sandbox?
Good question @Henry-Hiles. So far I have only tested this without flatpak. The question contains two subparts. The first one is, that libbtrfsutil (and it's dependencies and Python bindings) must be added to bottle's flatpak. The other question is, if the flatpak sandbox intercepts the btrfs specific features? I have never done any flatpak building or investigated the details of flatpk sandboxing. Can someone with more flatpak expertise step in here?
It was quite clunky (and a flatpak expert might laugh at me), but I was able to test this branch in a flatpak today. I followed the meson build instruction in Bottles' Readme.md, and then build the release tar ball https://github.com/kdave/btrfs-progs/releases/tag/v6.9.2 inside the flatpak's bash shell like this:
./autogen.sh
./configure --disable-documentation --disable-lzo --enable-python --prefix=/home/johannes/src/Bottles/build
make -j
make install
export MY_PATH=/home/johannes/src/Bottles/build/lib/
cp libbtrfsutil/python/btrfsutil.cpython-311-x86_64-linux-gnu.so $MY_PATH
LD_LIBRARY_PATH=$MY_PATH PYTHONPATH=$MY_PATH /home/johannes/src/Bottles/build/bin/bottles
Then bottles can import btrfsutil, and everything works as expected:
- Bottle duplicate as subvolume
- Create snapshots
- Reset state to snapshot
- Deleting the bottle deletes the corresponding snapshots
Today I dived into flatpak building, and added the needed btrfs-progs package to bottles' flatpak build. I also moved the corresponding git commit back into the history, in order to avoid commits, where bottles' flatpak fails to start due to the missing btrfsutils module.
Hey @Borgvall, are you still interested in working on this? It seems like, based on your tests, the functionality works inside Flatpak, so I'm all for pushing this feature in the future. I personally don't really like the current implementation because it's largely unmaintained.
Closing since there was no more activity.
@TheEvilSkeleton I am sorry, I somehow missed your comment.
I am still interested to add this support to bottles. However there have been some changes upstream, and this would need some rework. I will do this only, if there is some clear interest, to merge it.
I do have interest in it
@mirkobrombin ploase reopen this then. I am currently working to rebase and retest it.
can't reopen because the branch was force pushed, you have to send a new PR maybe using the same branch