[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: [e-mail]
          Reporter: [e-mail]
      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...)

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

https://bugs.winehq.org/show_bug.cgi?id=46226

mike  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

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

https://bugs.winehq.org/show_bug.cgi?id=46226

Olivier F. R. Dierick  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Product|Wine                        |Packaging
                 CC|                            |[e-mail],
                   |                            |[e-mail],
                   |                            |[e-mail]
          Component|-unknown                    |wine-packages

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

https://bugs.winehq.org/show_bug.cgi?id=46226

--- Comment #1 from Olivier F. R. Dierick  ---
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.

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

https://bugs.winehq.org/show_bug.cgi?id=46226

--- Comment #2 from Austin English  ---
(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.

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

https://bugs.winehq.org/show_bug.cgi?id=46226

--- Comment #3 from Olivier F. R. Dierick  ---
(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.

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

https://bugs.winehq.org/show_bug.cgi?id=46226

--- Comment #4 from Austin English  ---
(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.

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

https://bugs.winehq.org/show_bug.cgi?id=46226

Rosanne DiMesio  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #5 from Rosanne DiMesio  ---
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.

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

https://bugs.winehq.org/show_bug.cgi?id=46226

Rosanne DiMesio  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Rosanne DiMesio  ---
Closing wontfix packaging bug.