Request for discussion: Using PE libraries for Wine dependencies

[Zebediah Figura]

So I think I may have misunderstood or lost sight of goals somewhere 
along the way, let me try to review.

I think it makes the most sense to use one or more separate distribution 
packages for our PE dependencies, rather than distributing them as part 
of Wine, statically linking, or distributing them using our Win32-based 
addons system. I'm not sure just from reading this thread there's a 
general consensus regarding that, but I'm not sure I've seen anyone 
argue against it either.

Separately, I think it makes sense for Wine's libraries—seeing as they 
*are* (relatively, and mostly) high-level—to use MinGW libraries the 
same as any other MinGW-compiled program would.

It's not clear to me that this implies that we reverse the direction 
we're currently taking and try to make more use of the MinGW CRT, 
headers, and/or libraries. (I can understand the CRT part, though even 
then I have to wonder if there are differences that will matter.)

If it does, I'd like to understand why that's not possible, because it 
seems to me that we gave up on MinGW after they objected to taking the 
entire mingw-w64 project under the umbrella of Wine (and I don't think 
that was a reasonable thing for us to ask, given that mingw-w64's 
purpose is not to target Wine, but any conforming implementation of the 
Win32 API, and in practice mostly Windows.)

Now, on the assumption that using mingw-w64-compiled PE libraries is a 
reasonable thing to do...

On 4/13/20 11:38 AM, Jacek Caban wrote:
> So let me give a few examples of different choices packagers can do. I 
> will call wine-core Wine as we know today (which will not change 
> architecturally) and wine-meta-distro the proposed separated repo for 
> dependencies build system allowing a simple and straightforward way to 
> bootstrap complete Wine+dependences package, depending only on cross 
> compilation tools.
> 
> 
> 1. Not care, provide just wine-core package (addon headers are just a 
> build time dependency). Wine will download and cache addons in runtime.
> 
> 2. Use wine-core the way distro currently do to provide Wine package. 
> Use wine-meta-distro to build Wine addons as one but separated package.
> 
> 3. Use wine-meta-distro to produce both a fresh wine-core and wine 
> addons package in a single step for a single package.
> 
> 4. Like 2 or 3, but distro wants some customization itself. They can do 
> that, for example, by pointing wine-meta-distro to its own version of 
> relevant package, pass additional config options or do simple source 
> code modifications.
> 
> 5. Split Wine into 20 packages. A distro can use wine-meta-distro to do 
> build config stuff, so that they don't need to change their scripts 
> every time something changes in any of dependent packages, but otherwise 
> treat every dependency as a separated package.
> 
> 6. Split into 20 packages and deal with them without wine-meta-distro 
> packages. This will require packagers to redo all the work that 
> packagers choosing 1-5 will be getting for free.
> Your proposal seems to be similar to something between 5 and 6. I don't 
> expect packagers to be thrilled with that idea if they have 2-4 as 
> alternatives, by the key point is: let's give them a choice.
> 
> 
> 
> As a side note, a different and separated distro packages for, say, 
> libxml2 built with winegcc could also have some use cases. That would be 
> something potentially useful for cross compiling an application using 
> winegcc, but not something for Wine to use internally.

I think 2/4 are referring to the same thing (at any rate, I see no 
reason not to give distributions the choice). I don't think I fully 
understand how 3 differs from 2/4, or how 6 differs from 5. Do you mean 
by introducing a meta-package which only exists for dependency purposes?

Anyway, if depending on mingw-w64 really is a dead end, I guess either 4 
or 5 seems reasonable to me, though it's less clear that distributions 
actually would prefer 4. In particular, I notice:

* Suppose you want the versions of the PE libraries you ship to match 
the ELF libraries your distribution already ships. You can change the 
sources without too much difficulty, but how do you label the resulting 
package with regard to version? Naming it after the Wine version isn't 
great, especially if you're going to update those packages asynchronously...

* If a distribution (or even WineHQ) wants to update one of our 20+ 
packages, do they/we have to ship the whole wine-meta-distro again? 
(Maybe this isn't a problem, if the packages in question support partial 
updates...)

Ultimately I think this is something that actual distributors would have 
to answer, and I think we should probably bring some in on this thread.


If on the other hand we can depend on mingw-w64 libraries, I think we 
almost have to pick 5 over 4, for the simple reason that it's already 
done that way. There's an existing demand for mingw-w64 libraries which 
are distributed separately. Fedora already ships them. Arch doesn't (in 
fact, Arch doesn't even ship the mingw-w64 compiler), but they exist in 
the AUR as separate packages, and I myself use a third-party repository 
that ships mingw-w64 library blobs. (That's how I was able to write that 
msxml3 patch, in fact.) Debian/Ubuntu don't ship very many, but they do 
ship libz, and also development versions of a few other libraries.

> 
> 
> Cheers,
> 
> Jacek
> 
>