https://bugs.winehq.org/show_bug.cgi?id=46226
Bug ID: 46226 Summary: [IDEA] Split wine in multiple libraries for use in container formats Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: okgomdjgbmoij@gmail.com Distribution: ---
Now container formats( appimage, flatpack, snap) are all hyped up. A reason for this is probably available bandwidth.
A windows developer could decide to make a container package for his app. But right now, it's inconvenient, as he must put in everything from wine, including the kitchen sink. If they were official wine libs, packagers would have an easier time packaging windows programs, since they would include what's actually needed. Also, they could pick libs of different versions, depending what's more compatible for their app. Instead of been forced to use one giant package. Since normal users could find the best lib combinations by trial and error, for a particular app, it would make it easier for the devs to simply use what users have found.Right now, inconvenient hacky ways with strace and sed -e are used.
I'm imagining that for the distro, you'll have a wine meta package, that depends on certain wine libs, and been able to install many versions of the same lib. The user can always install an other meta package, or a custom one. For example wine-starcraft or wine-photoshop as opposed to wine-generic. So you run starcraft with that wine, and it automatically uses the correct libs. Or fine tune the libs used in wineconfig of a certain bottle. Packagers could fine tune the installation for a container package that never brakes, with just a simple apt command in their chroot, not with hacks and binary edits.
That would be a more convenient solution then what lutrix/playonlinux is currently doing. Even they, they try to pick the best wine version, they don't pick and chose individual components between different versions of wine. If wine X has functional component x and wine Y has functional component y, currently the application will simply be broken and have an additional garbage app in the database. Steam/proton might be interested in something like this.
Also it will be more convenient for Proton/ReactOS or who ever wants to fork parts of wine for their own little niche reason, since they could still directly use upstream libs.
For testing, this will also be more convenient. You have something that half works, you change one lib at a time to see if it works better...
To make the process as easy as possible. The libs should mirror the libs in windows, so that to minimize resistance from windows developers.
(Yep, yet an other stupid idea...)