On 9/7/21 2:12 AM, Richard W.M. Jones wrote:
On Mon, Sep 06, 2021 at 05:59:41PM -0500, Zebediah Figura wrote:
Thanks everyone for their input.
There seems to be a consensus that Fedora would prefer that we use their MinGW dynamic libraries. However, this leaves a couple of questions:
- As I described in [1], we *may* be able to hack things in the Wine
loader such that we can use unmodified dynamic libraries. However, it's not fully clear yet that it's feasible. If it turns out to be infeasible, what preferences does Fedora have? (Renamed dynamic libraries shipped separately, shipped as part of Wine, static libraries, etc...)
Adding -static subpackages is the easiest option from our point of view. As I mentioned in the previous email this would mean adjusting an existing spec such as: https://src.fedoraproject.org/rpms/mingw-gnutls/blob/rawhide/f/mingw-gnutls.... so that it builds the static library. It's a simple and obvious change.
But can Wine use the static library built this way unmodified? And are there any other implications versus using a DLL?
I believe we should be able to use unmodified static libraries, yes.
There are the usual implications—more space on disk and in memory; in Wine's case it doesn't really matter a lot, but we do still have cases of multiple DLLs that use the same library. It may be possible to use helper DLLs to avoid that in most cases.
And, of course, I hate developing with static libraries :-(
- Since most other distributions don't ship any mingw libraries
(yet), and since Fedora doesn't ship all of the libraries we need yet either, we will probably need to include code in wine to fall back to imported sources or submodules. Is this acceptable to be used in Fedora, at least on a temporary basis?
There is a bundling policy:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
As a general rule of thumb it's better if the upstream package can be either configured (or maybe automatically) to unbundle those dependencies for which system equivalents exist. eg:
./configure --without-bundled-gnutls
would use the system mingw-gnutls. Without that flag it might use a bundled version that it carries along.
The bundling policy matters because of security concerns.
I would say the other thing about bundling: Please don't add private patches to the bundled libraries! Huge pain for distributors because it effectively means we have no idea what is being bundled, which again has big security implications when someone has to work out if some bundled library is vulnerable to a CVE. Get the patches to the upstream projects.
I'm pretty sure we don't want to add any private patches, so at least there's that.