Date: Mon, 19 Feb 2024 18:34:19 -0800 From: Mark Millard <marklmi@yahoo.com> To: Dewayne Geraghty <dewaynegeraghty@gmail.com> Cc: Rozhuk Ivan <rozhuk.im@gmail.com>, aryehfriedman@gmail.com, FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: FreeBSD ports community is broken [port building configuration notes] Message-ID: <7B21AFF0-E0D5-4836-8486-F812E79152DF@yahoo.com> In-Reply-To: <CAGnMC6qkzYTXTEsV1xy=YRtg8_=-SXzO92E2W%2B6J1vtxOCpCGQ@mail.gmail.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> <CAGnMC6qkzYTXTEsV1xy=YRtg8_=-SXzO92E2W%2B6J1vtxOCpCGQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 19, 2024, at 16:37, Dewayne Geraghty <dewaynegeraghty@gmail.com> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7B21AFF0-E0D5-4836-8486-F812E79152DF>