[Bug 46226] New: [IDEA] Split wine in multiple libraries for use in container formats

[wine-bugs at winehq.org]

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 at winehq.org
          Reporter: okgomdjgbmoij at 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.