From nobody Tue Feb 20 02:34:19 2024 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 4Tf3QN6cKJz5B3WS for ; Tue, 20 Feb 2024 02:34:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.31]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Tf3QN3WH2z43sL for ; Tue, 20 Feb 2024 02:34:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708396474; bh=Q5D2khmVgPbu3TQwGgnF7+gsFIhDCTSx7PvMbUBXhMs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=M01LBLBBpKJQdIETVckwFyF8rLufJuE6AL0J7XHZZQx704bD+lUIMxBkEWfyDM6tkvLhoQeChG03htFpxPUldaTXzC5Cssv+IzWu9RXAFS+ztsOG4PVWb1ohbw75Yk/rOcSyFAK8efAyX7jBrDNYLSfOiwsrJLFoQYkkOVGFsbWGj64H75X1dCjL0OguoweR140RSycvpfnaQ61cgcGskNhdPIO/KzigTfIWOZwALdevwYrCmmEyinGUO68n0AWdrJLUXVB55XGq5Ix9hXccMU5is2V93roCbbBeFCf3+6dkjP3mDqVc4SR1SsZxWKi7bQtjc+yv2L5ZmWdc2i9VIQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708396474; bh=Ay3muRnbnrUpP2TBjDwh3dkmjP6KOaYEHKz/hijQu0o=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=g73+gMxw33NVQWGhlAu4CX+QF/2z9YXHYKPqDHhj5mbkW7oac5rTNCRg06qGmuKT6X82meJwh73SiKrd4CL+0Q9d90vPGwoiFbZGhrjXnqklcOgkM3KZZj6PUD3qfiplO7PfwVwJ5S6qTncn+K216s2HSPUACp7Bh9spfPo7dYygS0yCCK0Cmv1VWhnnK4POscxWPOuTifZZSslawPqtk6z21quoYPhIvXqmHgbELzn32vUIgLVZuQOkurmMynxgrO8HrX0VW/aoO9acLc4Pa1j65oqweNan87nr/5tjY0vYz+uCzJ8/1Q6uifwhscXd9taAl1NxEhxiE3mz9zkvig== X-YMail-OSG: SMrNyEIVM1kBYJqxEQPhjFJUvHvRLPQbPcxMxwrhp6Ur.7acOFmoFlEHJ8EGRYJ gV9Xv65ZrZtlfjXSxTySW8BjISfIEsvZLuwlL.yeOlattvh6mG.yt7EZ4RNqSHXu4uzW5KTvOtE7 q7TEL9qHJJKJjlWWCJW9tHLI91B56Zn2XxTQow5rZap5N3XCLx8TR872dbPJeL4a9gRs1AKR4vPl pNcJ.4Q9_0n2H7vPIGS.Kx8kaTiAZ4D8jRF6hV.CKF2x6H1PM9O26CPUlMB4P5wCgx0DFsTpr6aP YpNj1wT7Zo_kTEvNKuM7eKY2QxgN5V1gORT9uadAMImdFkQWvaH3VcbTxQodbq53cnddmt.FXmoR PF6ettbppkrFINrOJg5XMXam3HeH.jAcqpMOwPGhVQiM9KOnxBdVNck6PEToHmL96x9g1n6uQ6pR XNj46gSXv8Fhaf_AzPMf61KFFfN56M5TJ2zEycazupO2NijWFpHKcJnBMinyCiWggVI0V1k8GU2l M0vol2KeKI0V8Exb8Ai6mXrYcRKjaQeg2FmVUVTnNpGoSlQ5TJ84kuXN59fy6Abx12xipEbRVNhf y.RT7Ud5DpPxL9q2nPSo4cWJZ0G8Bh30jxV2YW_XLMoNzkiRz8H0Qmgp5EPphKX62efTaqSfa9jE pqSJSTLHvIiScNcn90rFlEHHmmMt_JliPa7qutHUtUsymPVE4ZwuhJPj2BJnOqamGIhyHI5va9bR QozjG9psPDd0.1xdCwhEek2fNnUk_aEJn2PMxrRZv2EVWoCOiYle38pom4wwytRwN1QQMPuTS_Xu NPFA6juEC2Yd.iJy8ewwOFv572eHSDXTmrDStBxcU2dSPHxpzJnKX2F_bi9XGSdfn1P4uoPiwKdS vxZZbSRbz6l2VEJhLOn6evixePSD.FKnz0lAJI8YRXGxlUwVFXfFdDit3ilL7BeNd3Tr1XW4QSxB yWhmGEJ3Q5lrU_N9FHfmFPfBxaT1Q3Ubrr6EO2NYBjLLHYsAo0AifCDAiNtGMDFNR9uk6M8fYQuv eDJC__5IbnDStDGllgw6WawjZb7mpd.yGZ2uZEyFgY72aeMjWVNTSS93EUjrzvJdQUo.Ea7qICYO UynZr4FvDKf_0Ajjr9xThJ9NCeUe9ZaR9_2q0jwlsuL9MWz2QoQUidMXD98h3AU1H_AxfCk1wsvY JUSlAqnoYLSwX70IbfK.5mmuFFrsW1COy32hjkGJbJDHnuPMiGj_29C2yK4ulEy2HnMwEgWhWihW PdmyJ5A0ZR0K3Z_Usupwe7_Bw.yaa74UXZwdGde4NJWu1ogXEFI60hjxvl5FR2u0NNjjWYsvNpBt OiswjnG5VsU8y3MSN_nd8kpZ1yqhQ6r0zzDmBCeEWSiYDJ3RpYY6u0gGoNkw9.ZEGCKI2._N4gub LIkZ31RtPdPFoj.WxkiAukXOHyk8mZTEl72X.h5osPY7Ho3y36.kOm7sFkC48fLPV5xLzvyFFZbg bj2Uy_xVWo3u5St6MPXqDtS_z5yRbCrkiLnMqDz5kw8AztUgsTZtMZjVBcM5v8qgdu8Xn41k__nQ 01SWSNXanQ6v1w8Chsy3QNu_7pdbjxC78lRX0w5sr3UybxLe1VEcK_AeEtIytfUgA9Yw2KwY4KuJ qimqpbcBTs3nA7GtitH9MLf2bcFAj9144g3Pbo4INqH5DzQVm_O9OZu5kwHxdfpHFbEdQn_oa9vj q3epp8AaeYA2yq_GBQ9GfRkkpyrmi2zM3BBI5zybdrK1UGzDQAA6ILjDKJekVAj5W4.DFAr2WcT4 0CrddhhDrkFUZ3UnNlo4i.FXjJpdyu1c6Y0Myw37rAfNSn75bG_9EH4q6sz_5FSKr5db5Cx2Svuk 9hx8wdX9Dmqvly75jtHnEOcpse6_7yldu90rHg6D2OFkS8pR3GH9Oo5RLm48bt4VpiZbf7mtbt0y K6J8F1QRG0J3GxzeUp7nI8lcnDZS3hYNafDdRnO3ZixIqSNn53X3DK5rnE9KTIUNE3PhtiXdrGQD nUqnUvMEm7Gh6F7JkvXLU3X84cd.3yiZZWdS_pelrl.QspfOd4Qd2XfmLUAhCJ.MhGMIZGp5ga.Y j5MDZDTU5uVr150SKc3t2CjfbsoL4GDGykREil8SFXSVt7RDRzgg8ke3UQAKGumKvLOr3R8VordI CwhumseUJnxZr2qmpUg.D5bi8j1d0NGjU4NXUGOAW7GbQ5qVWfqXny2PLEnBVhvLDxLFOPgfAm8c lR19UxAleFHB5CChdxImE_NmIVL0EJBMKYWUBbmElhE.mikPeeeKlNHgHapJp6MPPAATHCtLI5J4 qRQ-- X-Sonic-MF: X-Sonic-ID: aa9e868f-2290-4e65-ae12-5be13c75b0d8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Tue, 20 Feb 2024 02:34:34 +0000 Received: by hermes--production-gq1-5c57879fdf-9nrfh (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 0ff2ecfd63223c1abcd43b4a30e3071f; Tue, 20 Feb 2024 02:34:30 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: FreeBSD ports community is broken [port building configuration notes] From: Mark Millard In-Reply-To: Date: Mon, 19 Feb 2024 18:34:19 -0800 Cc: Rozhuk Ivan , aryehfriedman@gmail.com, FreeBSD Mailing List Content-Transfer-Encoding: quoted-printable Message-Id: <7B21AFF0-E0D5-4836-8486-F812E79152DF@yahoo.com> References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1.ref@yahoo.com> <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <20240219104333.6ecff336@rimwks.local> <8C4AB1AF-139D-4144-867C-6AD1AE1E1307@yahoo.com> To: Dewayne Geraghty X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4Tf3QN3WH2z43sL X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] On Feb 19, 2024, at 16:37, Dewayne Geraghty = wrote: > It seems that the ports developers have a tool that they would like = everyone to use, while members of the wider community want choice. I'm not a port developer but I use poudriere to build ports (into packages that I install). I used to use portmaster and so am (was?) familiar with that context. > Context > For my part I appreciated Hubbard's pkg_* tools. Later pkg* and the = ports infrastructure underwent substantial change. After a few years = pkg and the ports infrastructure settled down, improving the build flow. = The ports infrastructure and maintainers' Makefiles enable the task of = building applications tremendously simple. Though I've often cursed the = constant additions to the ports infrastructure (/usr/ports/Mk, Makefile = syntax, pkg), the improvements are accessible, understandable and = substantially transparent. This is a better end-user experience. [I had a question here. But the context was better handled in later material below.] > Poudriere adds another layer to the pkg -> ports infrastructure -> = Makefile flow. Which is ok, but the changes are often opaque and near = impossible for end-users to change. It probably should be separate from this topic, but I'd interested to understand some example types of changes folks make for which poudriere prevents the changes from working but for which portmaster use or make use allows the change to work. I have seen reports about ports that are broken when not built in poudriere's simpler builder context. I've not seen much about ports that fail to build only under poudriere but that systematically work via the likes of portmaster. Are any port changes being rejected because they fail to work in poudriere? (I've not noticed any examples.) It would seem that only failure under poudriere leading to rejection of desired changes to the port tree could possibly be strongly blamed on poudriere itself. If something works built via poudriere but not via portmaster (or the like), there is room for more port development so that portmaster or the like also work. But the failure when the build is attempted via portmaster (say) is not something that could reasonably be blamed on poudriere itself. [There are other rejection issues going on that do not fit the categories I've indicated, such as rejections that in part are reported to be because poudriere builds already work. I'm not trying to address those here --but finding folks willing and able to develop for portmaster or the like can be a challenge of itself when working-via-poudriere is easier to achieve.] > portmaster shell isn't easy to navigate but it is a simple tool that = fits the needs of very many builders. =20 >=20 > The end-user should be the topic of focus and keeping them engaged and = using the FreeBSD platform with 'easy to build applications' the = objective which leads to advocacy and growth. I'd say that the official pre-built packages are from a focus on end-users that are not also port developers and are not getting help from port developers that tailor things for them (the help leading to not using official pre-built packages). This might or might not be the larger end-user group compared to . . . End-users that are getting help from port developers to tailor things for them is another group. (I'd count personal port tailoring here as well --my category.) I can not tell how common this is vs. use of just official build of ports into packages. Focusing only here has its own potential problems. > History > As a newbie I used the packages that were available in FreeBSD 2.2.8 = which flourished my use of "the system". Over time I realised that the = ports maintainer's option choices didn't reflect my needs. Now I have = 490 changes to the ports options and modified 233 ports' Makefiles and = files/. This customisation is based, in priority order: security, = features, performance. So for me the ports system is fantastic, without = it, it would be impossible to maintain the 2400+ ports that I use on our = servers.=20 I have changes to port options, have modified port Makefiles, and have extra/modified patches in files/ --but on a smaller scale. I've yet to have poudriere use interfere with any such changes that I've made. I use (for an example amd64 context): # poudriere ports -l PORTSTREE METHOD TIMESTAMP PATH default null 2021-04-18 09:05:47 /usr/ports that has my modified ports tree. I also use my own builds/installs of the world(s) used for the jails: # poudriere jail -l JAILNAME VERSION ARCH METHOD TIMESTAMP PATH main-amd64 15.0-CURRENT amd64 null 2021-09-09 07:43:44 = /usr/obj/DESTDIRs/main-amd64-poud main-amd64-bulk_a 15.0-CURRENT amd64 null 2021-12-04 22:55:22 = /usr/obj/DESTDIRs/main-amd64-poud-bulk_a (My world builds are also somewhat tailored, as are my kernels. "bulk_a" stands for "bulk alternate", which on rare occasions is used for "bulk -a" as part of some sort of test in/of my environment.) > An expectation that only packages should be used by our wider = community is a false assumption for anything other than novice personal = use.=20 Did you mean "official prebuilt packages" above? If not, how does involvement of pkg for non-official build of packages become a problem? Also: portmaster builds packages (-g), makes backup packages of installed ports (-b and by default for deletion), and more. This again suggests that the "only packages should be used" reference might somehow be an incomplete context identification? > Changing the ports infrastructure so that a build requires poudriere = is wrong and as we're seeing divisive. As far as I know, anything made to work with portmaster or the likes also works with poudriere and the infrastructure has no enforcement of poudriere-required anywhere. (There can be other forms of such.) It can be more work to have portmaster like builds/installs work in the full variety of live contexts. But when it does, poudriere should just-work for building/installing as well. Other forms of blocking things that would work for both portmaster (say) and poudriere is not what I'm trying to deal with here: just infrastructure issues. (But: I've no clue if subpackages might be introducing infrastructure ties I'm unaware of.) > The PR's are also a cause for hesitancy (see ref below)=20 >=20 > Regards, Dewayne >=20 > Ref:=20 > 1. = https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=3D__open__&list_i= d=3D672566&query_format=3Dadvanced&short_desc=3Dports-mgmt%2Fpoudriere&sho= rt_desc_type=3Dallwordssubstr > = https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=3D__open__&list_i= d=3D672566&query_format=3Dadvanced&short_desc=3Dports-mgmt%2Fpkg&short_des= c_type=3Dallwordssubstr >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com