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...)
* 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?
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura zfigura@codeweavers.com 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...)
Would it be possible to use the MinGW static libraries to generate new Wine dynamic 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?
Yes, we have a policy that allows bundling for these circumstances, they just have to be declared: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
In the Fedora case, we'd simply force Wine to build using our system libraries.
-- 真実はいつも一つ!/ Always, there's only one truth!
On 9/6/21 6:31 PM, Neal Gompa wrote:
On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura zfigura@codeweavers.com 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...)
Would it be possible to use the MinGW static libraries to generate new Wine dynamic libraries?
Yes, although I think this ends up being worse than renaming them. You'd have to write some nontrivial linker scripts.
- 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?
Yes, we have a policy that allows bundling for these circumstances, they just have to be declared: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
In the Fedora case, we'd simply force Wine to build using our system libraries.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Mon, Sep 6, 2021 at 8:21 PM Zebediah Figura zfigura@codeweavers.com wrote:
On 9/6/21 6:31 PM, Neal Gompa wrote:
On Mon, Sep 6, 2021 at 7:00 PM Zebediah Figura zfigura@codeweavers.com 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...)
Would it be possible to use the MinGW static libraries to generate new Wine dynamic libraries?
Yes, although I think this ends up being worse than renaming them. You'd have to write some nontrivial linker scripts.
Also, most Fedora variants (especially the ones that Wine would be typically installed on) use Btrfs, which supports reflinks. I know that there is a patch set for implementing usage of reflinks for populating the Wine prefix used for running applications[1]. That patch set would probably help considerably for space efficiency of Wine installations on Fedora. Reflinks plus the renaming of libraries would probably mean we'd pay almost zero additional cost on-disk for the files for each Wine prefix. There's related work to also support reflinks in DNF and RPM directly[2], which should also help for deduplicating on upgrades and such (I imagine there's still some logic that needs to be done for the individual wine prefixes...).
[1]: https://www.winehq.org/pipermail/wine-devel/2021-August/193357.html [2]: https://fedoraproject.org/wiki/Changes/RPMCoW
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?
- 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.
Rich.
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.
packaging@lists.fedoraproject.org