Multi-version and review exception
by Remi Collet
Hi,
From Guidelines:
> Note that some new packages may be exempt from the review process.
> The package is being created so that multiple versions of the same
package can coexist in the distribution ...
We already have lot of packages in the PHP stack which seems to apply to
this exception (all have been reviewed)
And some other are mostly ready, examples:
php-cs-fixer3 from php-cs-fixer (v2)
php-doctrine-cache2 from php-doctrine-cache (v1)
php-monolog2 from php-Monolog (v1)
php-phpseclib3 from php-phpseclib3 (v2)
Can you please confirm that the exception apply here
and that I can use the fedpkg with --exception flag ?
Remi
2 years, 7 months
Re: Wine MinGW system libraries
by Richard W.M. Jones
On Tue, Sep 07, 2021 at 06:13:32PM +0200, Ondrej Mosnacek wrote:
> On Tue, Sep 7, 2021 at 5:45 PM Zebediah Figura <zfigura(a)codeweavers.com> wrote:
> > 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-gnut...
> > > 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 :-(
>
> Could you perhaps just build a new dynamic library (with the adjusted
> name) by linking an empty/dummy object with the Fedora-provided static
> library? (Not sure if that's possible, but it's what came to my mind
> when reading this thread.)
I doubt this is going to be possible. Windows PE DLLs have some
complicated machinery for declaring exported symbols. Plus (like ELF)
I imagine the compiler needs to generate quite different code for
static vs dynamic.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
2 years, 7 months
Re: Wine MinGW system libraries
by Zebediah Figura
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.o...
2 years, 7 months
Wine MinGW system libraries
by Zebediah Figura
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
[2] https://fedoraproject.org/wiki/Bundled_Libraries
2 years, 7 months
