Re: FreeBSD ports community is broken [port building configuration notes]

On 2/20/24 06:13, Jamie Landeg-Jones wrote:
> Mark Millard <marklmi@yahoo.com> wrote:
> 
>> 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've many changes, nothing that would upset poudriere though.
> 
> I've probably grasped the wrong ideas from this thread. I thought it was
> about the implied effective deprecation of the ports infrastructure for
> a binary package only structure, with poudriere being used to create
> custom packages in any way it wants going forward.
> 
> If pordriere continues to build via the make system we have already,
> then I can't see any issue.
> 
> What's the reasoning behind people claiming a shift from "make install"
> to poudriere is necessary?

   I don't consider it necessary, but building in a clean environment is 
desirable to minimize issues and maximize uptime. Some ports will fail 
to build or install when certain other packages have been installed; 
proper solution is to open a PR to get such cases identified and 
resolved. I'd go as far as to say a port should be marked as 
incompatible with itself if it uses already installed tools from an 
older version of the port or from a non-dependent package in place of 
ones that were built in the port's work directory as I have had builds 
fail doing an x86-x64 rebuild+reinstall step without first removing them 
(likely to be unsupported) and when trying to perform a general upgrade 
of an installed package/port (should be supported). Fixing the port's 
build system would be much more desirable to marking it as incompatible 
with itself but if a condition is detected where builds can go wrong 
then it is better to mark it as broken than let the user fail trying.
   In the past, I have reported such breakages and even when pkg-plist 
needed to be conditionally altered if something was already installed 
and maintainers addressed the issues accordingly. Dynamic dependency 
testing that a port's build system does should be changed to be manually 
fed a list of dependencies based on port options or the dependencies can 
be unconditionally added to avoid surprises that people get building a 
port on a clean machine vs one with an optional dependency already 
installed; it isn't 'necessary' but creates better conditions for 
packages to always match what a user could get and gives everyone less 
surprises.
   I have had other issues in the past by old remaining files from bad 
pkg-plist leaving things behind, unclean work directories (I hope this 
is not why the workdir is currently a version dependent folder; that 
practice needs to stop to greatly improve ccache results), and 
dependencies getting out of sync if port versions were not properly 
recursively bumped.
   When it comes to upgrades, a clean build environment is superior. 
Software often won't work when an upgrade has been partially performed 
which can break on the first run/lib dependency and isn't usable until 
the port itself is rebuilt after. That leads to a downtime of hours to 
days depending on how much work the machine has to do to do an update. 
If the upgrade fails partway through, software may continue to be 
unavailable until a port is fixed or downgraded to a previously unbroken 
version if no older package was saved to reinstall. Recursive dependency 
version bumping has had issues.
   As for my use, I'm a desktop user currently on older hardware and 
have felt my own pain learning how to try to use poudriere with it. 
Wonder if thigns have changed because 13-stable feels more painful than 
I remember when CPU gets heavily loaded by idprio'd processes. 
Poudriere's defaults are not sane for a modern desktop user but I do not 
have a 'good' non-manual fix until we start recording various build 
requirement details into ports themselves (which is an idea needing its 
own topic).

> Cheers, Jamie
>