WINE requires 32-bit libraries for many programs. The current system
used by the WINE port is to require the user to run a helper script
which uses pkg to fetch and install i386 packages to the home
directory. It is not ideal.
The WINE project's promised WoW64 thunks for 32-bit processes to use
64-bit libs has been in "almost there but not quite" status for years.
The motivation to maintain 32-bit libs for WINE remains.
Several proposals have been made for 32-bit library ports:
- A single i386-libs port uses a chroot to build many libraries from
ports tree which are then installed/packaged as one port. Unacceptable
since a port must not require root to build.
https://reviews.freebsd.org/D14721
- Create i386- slave ports of all required libraries. Filling the ports
tree with ~100 arch-specific additional ports seems unacceptable.
https://github.com/shkhln/freebsd-lib32-companion-ports
- Add -i386 flavor to all required library ports. Clutters ports'
Makefiles and may conflict with existing FLAVORS uses. Not using
FLAVORS as intended. https://reviews.freebsd.org/D16830
- Write a single i386-libs port. Each library is built as a separate
package as a FLAVOR of i386-libs. Unconventional usage of FLAVORS.
All reviews and efforts on this seem to be dead as a result of
uncertainty over whether the implementations are acceptable within the
existing ports framework.
For thoroughness, some of the ideas previously discussed which are
surely unworkable and don't deserve any further consideration:
- Create an amd64-lib32 repository that may be used by pkg alongside
amd64 repository. Completely outside of normal dependency mechanisms
and leaves direct users of ports tree without a simple procedure to
build i386 libs.
- Ports overlay
- Have an i386-libs metaport do evil variable manipulation of port
framework dependency recursion to create i386- variants on the fly.
Maintenance headache and incompatible with poudriere. Procedure for
rebuilding specific ports is non-obvious to the user.
Single i386-libs port with each library built as a FLAVOR seems to be
the least bad option. However any work on it, even a minimal working
review, is a waste of time if this particular usage of FLAVORS is dead
on arrival to portmgr@.
WINE port Makefile example:
LIB_DEPENDS= ...
${LOCALBASE}/lib32/libfontconfig.so:emulators/i386-libs@x11-fonts__fontconfig
emulators/i386-libs/Makefile:
PORTNAME= i386-libs
CATEGORIES= emulators
MASTER_SITES=
DISTFILES=
LIB32_PORTS= \
x11/libXrender \
x11/libX11 \
x11-fonts/fontconfig \
security/gnutls \
print/freetype2 \
graphics/vulkan-loader \
graphics/libGLU \
devel/sdl20 \
graphics/mesa-libs \
(... many more ...)
FLAVORS= meta ${LIB32_PORTS:S,/,__,} # category/portname ->
category__portname
# ${FLAVOR}_*_DEPENDS to be derived from a ${MAKE} -V into referenced port.
# emulators/i386-libs is not a slave port.
Considering the lack of better options and the situation that FLAVORS is
the only currently supported mechanism for a single port to build
several packages, will the slightly unconventional use of FLAVORS be
acceptable provided the port conforms to quality standards in all other
aspects?
