[RFC PATCH 0/5] XAudio PE conversion.

[Zebediah Figura (she/her)]

Sorry for the slow reply, I'll admit I didn't really want to get into an 
involved discussion, and I don't particularly expect to get anywhere, 
but I'd at least like to try to explain my reasoning.

On 6/23/21 1:38 PM, Alexandre Julliard wrote:
> "Zebediah Figura (she/her)" <zfigura at codeweavers.com> writes:
> 
>> I know that dependency management (and ABI compatibility, for that
>> matter) has fallen out of style in some circles, in favor of
>> statically linking everything or shipping all your dependencies, but I
>> really don't think that's a good thing, it has easily visible negative
>> effects, and while I don't really want to get into an argument over it
>> I also don't want to see us adopt that philosophy without question.
> 
> It may be questionable from a philosophical standpoint, but that's the
> world we live in. Linux distros don't care about backwards
> compatibility, and I have no reason to believe that this is going to
> change, or that they would do a better job with PE packages.
> 
> And honestly, building our dependencies as PE and linking them
> statically would make things so much easier for everybody, that there
> would need to be strong practical reasons to go out of our way to start
> relying on distro packages for this. A general dislike of the approach
> is not good enough IMHO.

Mostly what I'm trying to advocate for in this thread is that we ask 
distributions what they want instead of deciding for them. Just because 
static linking might be easier for them doesn't mean it's what they 
actually want, and I think there are salient and good reasons why they 
wouldn't want it. Now, if we have that conversation and nobody wants to 
ship dependencies themselves, I'm prepared to shut up and deal with the 
decision; I won't be happy about it, but I seem to be in the minority at 
least among Wine developers here.

Not least because I'm not convinced that "Linux distros don't care about 
backwards compatiblity", or (as implied) that they don't care about 
philosophical correctness. I get the impression rather that some 
libraries don't care about backwards compatibility, and don't give 
distributions a choice in the matter. I'd really like to not see us 
become one of those, at least with respect to not giving distributions a 
choice. And I think that distributions broadly *do* care about 
philosophical correctness (as arises from practical correctness!) as 
evidenced by the Debian/Fedora/Gentoo policies linked earlier in this 
thread [1] [2] [3]. (Yeah, they're mostly talking about source imports, 
but some of the arguments apply to submodule-type dependencies as well.)

I get that we may have been burned in the past by breakages that have 
been the distribution's fault, but I think the response to that 
shouldn't be to break off negotiating with them and do what we think is 
right.


Now, with that said, here's some reasons, which I'm hoping are both 
strong and practical, that we should rely on distribution packages. Some 
arguments for not embedding or static linking don't really apply to PE 
dependencies, because they really are a special case. But others do:

* Projects that import source take so much longer to build. That applies 
whether the source is baked in, statically linked, or even built as a 
shared library. The last two cases actually often get worse because the 
build system needs to recurse (but baked-in source has its own 
problems.) This is probably the top reason I absolutely hate 
contributing to wine-mono, and why although it's my job to work on 
Proton I avoid its build system like the plague (preferring instead to 
compile individual Wine modules). [4]

   I as a DirectShow developer need to build GStreamer anyway, for 
various reasons (I need the latest version, or to fix an upstream bug, 
etc.) But I've never needed to compile FAudio from source, and I don't 
want to have to take that extra time during a Wine build. Relying on my 
distribution package makes things much easier for me.

* Static linking makes bisects painful. You have to rebuild the 
downstream project every time. Shared libraries would be a lot better, 
for this and for other reasons. Even if the decision ends up being to 
distribute libraries ourselves I'd like to advocate that they be shared 
rather than static.

* By linking libraries statically, or by linking them shared and 
distributing them ourselves, we are taking up more disk space that could 
be shared. This is obviously a garbage argument because no other 
application is using PE libraries, except that:

   (a) some distributions [5] and unofficial repositories [6] do ship 
MinGW libraries, which means that there *is* a demand for them outside 
of Wine, and

   (b) if we link them statically, even within Wine we'd be sharing many 
libraries across several modules [libvkd3d and libvkd3d-shader across 
d3dcompiler_*, d3d12, dxgi; libfaudio across all of the many xaudio 
modules; even libmpg123 across l3codeca.acm and mp3dmod!], and to avoid 
this we'd have to use some sort of manually defined static -> shared 
shim. At that point distributing the shared library seems like less work.

* This might not be under consideration, but I'll mention it anyway: We 
may have gotten used to the appwiz prompts, but they're honestly an 
awful user experience.

* Submodules are not fun to deal with, particularly the part where 'git 
submodule update' forces you off a branch.

ἔρρωσθε,
Zebediah

[1] https://wiki.debian.org/EmbeddedCopies

[2] https://fedoraproject.org/wiki/Bundled_Libraries

[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies

[4] As a bit of an aside, this may be my top complaint about modern 
dependency management. It makes things easier for the project 
maintainer, and for people who work on the project all of the time, 
because they have to build everything from source anyway. And it makes 
things easier for the end-user, because they don't need to take any 
extra steps when installing [and often need to take less!] But it makes 
things much worse on the developer of a downstream/upstream component, 
or on the end user who needs to compile the package for some reason.

[5] 
https://packages.ubuntu.com/search?suite=hirsute&section=all&arch=any&keywords=mingw-w64-dev&searchon=names

[6] 
https://martchus.no-ip.biz/buildservice/#package-search-section?name%3Dmingw%26mode%3Dname-contains