Date: Wed, 23 Aug 2023 15:05:05 -0400 From: Theron <theron.tarigo@gmail.com> To: FreeBSD Ports <freebsd-ports@freebsd.org> Cc: portmgr@freebsd.org Subject: Getting lib32 porting effort unstuck Message-ID: <1394819d-69c2-2724-d3cb-38b82046cb2b@gmail.com>
next in thread | raw e-mail | index | archive | help
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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1394819d-69c2-2724-d3cb-38b82046cb2b>