From nobody Wed Aug 23 19:05:05 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RWFzr1zHwz4rG1j for ; Wed, 23 Aug 2023 19:06:00 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RWFzq4WsTz4nRk; Wed, 23 Aug 2023 19:05:59 +0000 (UTC) (envelope-from theron.tarigo@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=ag5qSJXe; spf=pass (mx1.freebsd.org: domain of theron.tarigo@gmail.com designates 2607:f8b0:4864:20::732 as permitted sender) smtp.mailfrom=theron.tarigo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-qk1-x732.google.com with SMTP id af79cd13be357-76de9bfd53bso67593885a.2; Wed, 23 Aug 2023 12:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692817558; x=1693422358; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=4XFl3VubOH/QPung89OBuP1qzirdjI6bOSErvS5txQw=; b=ag5qSJXeqoXpnwimvflU/Pzd8HBLihxcASvjVBghWuJGBeAzcAVJVLPBcbTxrUTcrC 5R3t9Hpc0Do5glFq+hu1wGTtMi7j2O3s9INvpBpAI354Knq2sJMmSLlWAIGzaau5ryP/ F6cc4h6Rzl9nF+WN92Qhc5eCcxZBDn3ewk6pvDHTTmA39TBMy1fE5FXmc6lpMk/8ZtZ2 2po7sWTnjxDR95EuEIi0le8cXWJw2hxmmmalN6vnbJZA+0vPZaQm1dkgbXfUV/caJQK+ T82IRron1OzSvjdk8DxZ/6LrmrHML9d52zCKO/fK9Yq/k70ycz9OE89kvCPUDmHq1/pl NxEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692817558; x=1693422358; h=content-transfer-encoding:cc:to:subject:from:content-language :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4XFl3VubOH/QPung89OBuP1qzirdjI6bOSErvS5txQw=; b=AZMR8HAS6gj62mC80+0qnyAC18wQYLniPCAZBNB53PVof8eshRWWTdf36yMYIE+hHW 2tXTF9x5fpkAqDi6CJ6bYv/Ua1jlRkzMcVgk2gCcIixddnZuHYK2k3ow5PaAlyN0rBrB F2wNXMvRKU8KqyMFYmmV/xxoExSNbxWXyek445bR+4l3EQsjnWug60b/xjxFbsDZEWlU kIHhwdgl/Zj9Jp9N0hkSjoATf4GQy7Pn+lE7hnrna0jI2/GMroijuyqVuaghbdCmUdZ7 6bTTkCSQrjxDOB1tiM9/L4uou/UXALQUUw2vzjEGmYfFdu1caSPeadK85PtcteFKUh3G EPMg== X-Gm-Message-State: AOJu0YyJ0oReTjj1kzV2ze3WQneHLjURmbQs4yMBMhoDDbJK3tXCwCVu Jy6GHx+Cr2rRSdv2g2OunEMOv+G3zHI= X-Google-Smtp-Source: AGHT+IEtp1Bm6df478E9DttaXdurmmwCIwQZRSFORT1Dqvv1SFZekAxyfY+C7ezCDi9uLTLhSR4FLA== X-Received: by 2002:a05:620a:9c7:b0:765:a74d:62b1 with SMTP id y7-20020a05620a09c700b00765a74d62b1mr14686045qky.19.1692817558232; Wed, 23 Aug 2023 12:05:58 -0700 (PDT) Received: from [192.168.2.30] ([71.169.160.48]) by smtp.gmail.com with ESMTPSA id o23-20020a05620a111700b0076dbaf97b75sm816250qkk.108.2023.08.23.12.05.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Aug 2023 12:05:57 -0700 (PDT) Message-ID: <1394819d-69c2-2724-d3cb-38b82046cb2b@gmail.com> Date: Wed, 23 Aug 2023 15:05:05 -0400 List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US From: Theron Subject: Getting lib32 porting effort unstuck To: FreeBSD Ports Cc: portmgr@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.98 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.978]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::732:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RWFzq4WsTz4nRk 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?