Bottles
Bottles copied to clipboard
bottlesdevs
[Experimental] Wine Layers
The intent of this feature (actually a concept) is to allow the user to use more than one environment (with different modifications and dependencies) in one bottle, leaving Bottles to do the hard work of making it all fit.
How it works
Let's add a fourth environment in Bottles: the Automated environment. A bottle created with this environment is basically a clean prefix, with only the essentials, so without any customization or dependency.
The user has access to only two sections:
- list of installed programs
- catalog of programs to be installed
When the user installs a new program from the catalog, Bottles downloads its installer, creates a temporary copy of the bottle and then follows the installer instructions (install dependencies, register keys, change bottle settings ...).
When the new bottle is ready, it compares the two bottles, takes all the differences and saves them in a new state in the overrides directory of the original bottle, then deletes the new one and adds the new program to the bottle's program list.
When the user starts the program, Bottles will mount the override on top of the original bottle and then start the program which will be able to find everything it needs to work.
Benefits
- Less space allocated than the use of multiple bottles. Currently when a software is not compatible with the environment of a bottle, it is necessary to create a new one.
- Shared directories, user files and installed software (although this will require tweak in the future) for each installed program.
- Control over what is installed and immutability of the original bottle.
- Ease of removing a program and then restoring the bottle to a previous state.
- Easy to use. In fact, the user will only have to worry about searching for the program and pressing install. Bottles will take care of everything, without requiring user intervention (unless the program we're going to install requires it).
Drawbacks
- The installation of a program takes some more time depending on the hardware as Bottles will have to copy the original bottle, compare the changes and eliminate the superfluous (Bottles already does this and normally takes a few minutes to create a restore point even when there are large files beyond GB, in this case it is a lot fewer files and I guess it takes a few seconds).
- Even the start of applications could be slowed down, since the override must be mounted on the original bottle (I always think a few seconds but it depends on the weight of the override)
This is just a concept. The feature is still in the planning stage and will see the light in one of the future releases as an experimental feature.
Have you checked if libostree could be employed in this concept? It uses checksums and hardlinks rather than copy-pasting, so it should achieve the same benefits without the drawbacks.
Yes, I considered it and I think it will be the final way. At the moment I have implemented a solution developed from scratch as a hidden feature to test the idea and understand if it was worth continuing its development (yes) but this will definitely be rewritten using ostree (it will take me a lot of time to study the documentation and I definitely need someone to help me).
Currently no longer just a concept as it is already present in Bottles (only for dev) and already manages the layers for dependencies and installers.
At the current dev. state, it cannot be used to launch a program, it will fails 9/10. For testing, launch bottles with LAYERS=1 env var.
It looks like the thing i was looking for years in the Wine environment. I definitely want to get rid to create entire wineprefix just for a program as it takes too much space on disk drive, but at the same time, installing everything in the same prefix has always been so fragile in wine (the versioning feature of bottles looks promising for that too).
About your design spec, it seems the only way to install a software is through a catalog of existing "installers". Will the user be able to install its own software (providing a "setup.exe" for example) or this feature will be limited to existing installers provided by bottles (or a community maintained repository of installers or something) ?
Basically only through installers to ensure stability and keep this new environment extremely stable and controlled. But I know the Bottles community well, so I will add an option in Bottles' Preferences to allow the user to launch external executable and create a layer on the fly even without an installer.
Our installers are based on a community driven repository, so it is better to create an installer when possible.
It will be a nice addition (at least for Linux geeks ), because i fear the drawback of this constraint would lead to the same issue as Lutris like a catalog full of broken installers, broken download URIs etc. because of a lack of a sufficiently big community to maintain a ever growing installer database, and simply prevent programs not in the catalog to be installed (catalog will never be exhaustive, Windows software ecosystem is simply too large).
Your solution seems a good balance between "clean and simple" for casual user, but not constraining users which are more confortable with wine internals
We are planning to fix the broken downloads and hashes using a GitHub Action, in order to automate the maintenance process. This obviously doesn't mean we don't need a community as the installers need to be maintained, but at least it will help.
Yes, but what if there is no alternative links available (archive.org can help here but not always) ? What if you becomes tired of this project and abandon it (you or other maintainers) ? i think it is important to not couple too much the software with volatile internet resources. One another use case is proprietary / professional licence software simply not available for download from the web (wine is used a lot in companies for that).
Anyway the idea of merging wineprefix diff is very great and i'm sure will make Bottles a game changer.
I don't know if this feature is still being worked on or planned, but a possible implementation could be done with OverlayFS, which provides a very easy way to mount multiple directories together, one on top of another while making the system view the final one as the merged overlay.
I hope I was clear enough, ArchWiki as usual has a more detailed explanation and some examples: https://wiki.archlinux.org/title/Overlay_filesystem
I don't know if this feature is still being worked on or planned, but a possible implementation could be done with OverlayFS, which provides a very easy way to mount multiple directories together, one on top of another while making the system view the final one as the merged overlay.
I hope I was clear enough, ArchWiki as usual has a more detailed explanation and some examples: https://wiki.archlinux.org/title/Overlay_filesystem
This feature is planned for Bottles Next. Sadly overlayfs is not a solution since they won't work on flatpak. I did some tests with FUSE overlays in the previous years, without noticing any performance issue, ant that should work even on Flatpak
Nice to know, I stumbled upon that technology and it seemed interesting enough to suggest it here.
But I'm glad that there is already another working solution.
Thanks!