[Bug 46226] New: [IDEA] Split wine in multiple libraries for use in container formats
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(a)winehq.org Reporter: okgomdjgbmoij(a)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...) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 mike <okgomdjgbmoij(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Wine |Packaging CC| |michael(a)fds-team.de, | |o.dierick(a)piezo-forte.be, | |sebastian(a)fds-team.de Component|-unknown |wine-packages -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 --- Comment #1 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Are you asking that the dll.so libraries be provided in separate packages? I see two issue with that: 1. If you replace a dll.so file with another from a different source, you'll run into ABI incompatibilities between the dll.so and the wineserver executable. 2. Multiple wine packages can be installed at once. Users will have a hard time installing library packages for the appropriate wine package. Overall, I don't see the benefit of such a 'pluggable' dll.so architecture. Just install the one or two custom wine packages that you need for your apps and you'll be going. App developers/packagers should NEVER package wine with their app but provide instructions or automate the installation of the wine package from its repository (official or custom). Users testing third party wine by trial and error is good for them but useless for developers: Most third party wine use hacks and that's why they stay out of official wine. And if an app doesn't run with official wine, file a bug report (if there isn't one already). Fixing bugs in official wine is better than requiring the use of custom wine packages. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 --- Comment #2 from Austin English <austinenglish(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #1)
App developers/packagers should NEVER package wine with their app but provide instructions or automate the installation of the wine package from its repository (official or custom).
I don't think that's true at all. If a developer wants to ship a version of wine that they've tested against and support, we've never discouraged that. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 --- Comment #3 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Austin English from comment #2)
(In reply to Olivier F. R. Dierick from comment #1)
App developers/packagers should NEVER package wine with their app but provide instructions or automate the installation of the wine package from its repository (official or custom).
I don't think that's true at all. If a developer wants to ship a version of wine that they've tested against and support, we've never discouraged that.
I'm talking about bundling Wine with the Windows app in a single package. If the user wants to use another wine version, he should have the choice to not download or install the version from the app vendor. If multiple apps are compatible with the same wine version, it should be downloaded and installed only once. Bundling Wine with the app goes against modularity, reusability, bandwidth and disk space usage. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 --- Comment #4 from Austin English <austinenglish(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #3)
(In reply to Austin English from comment #2)
(In reply to Olivier F. R. Dierick from comment #1)
App developers/packagers should NEVER package wine with their app but provide instructions or automate the installation of the wine package from its repository (official or custom).
I don't think that's true at all. If a developer wants to ship a version of wine that they've tested against and support, we've never discouraged that.
I'm talking about bundling Wine with the Windows app in a single package. If the user wants to use another wine version, he should have the choice to not download or install the version from the app vendor. If multiple apps are compatible with the same wine version, it should be downloaded and installed only once. Bundling Wine with the app goes against modularity, reusability, bandwidth and disk space usage.
Yeah, that's what Google Picasa did. It's also the likely result is someone ports their app with winelib. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Rosanne DiMesio <dimesio(a)earthlink.net> --- There seems to be a lot in here that has nothing to do with packaging, but since it's filed as a Packaging enhancement request, that's what I'll address. Short answer: absolutely not. If you're confused about why, try building individual packages for each one of Wine's dlls for every distro we build for yourself, and if you manage to get that far, think about doing that every two weeks for the rest of your life. And if you still think that's a good idea, we'll be happy to point users to your repository. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46226 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Closing wontfix packaging bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org