Quite simply, the process of building many of the ports in the ports
tree is highly dependant upon certain very specific things either
being set, or alternatively, not set, in the environment. But neither
the port Makefiles or the files they include make any serious effort
to adjust the enviroment, as necessary, so as to insure that it is
sufficiently close to the environment used by port tree maintainers
so that individual ports will actually build successfully.
As a result, the process of building many of the ports in the ports
tree (e.g. net/avahi-app, but also many others) will die in bizzare,
incomprehensible, and unexpected ways (see ports/140563 for an example)
if the user performing the build has, e.g., the variable POSIXLY_CORRECT
set in his/her personal environment at the time the build process
begins. (I do not know offhand if there are other such environment
variables/values that are critical to various port builds, but it seems
entirely plausible that there are perhaps many such others.)
To the best of my knowledge, there is _no_ documentation that instructs
port builders regarding what environment variables should or should
not be set when building either all ports, or any given specific port.
But in any case, such documentation, if made available, would still be
a poor substitute for proper and more reliable automation of the port
building process. Such automation should, ideally, set and/or unset
any any all environment variables (e.g. POSIXLY_CORRECT) whose settings
may be critical to the build process.
I see no compelling reason why /usr/ports/Mk/bsd.port.mk could not
be adjusted/hacked so that in future it would cause the setting and/or
unsetting of various environment variables, as necessary, to insure
successful builds of all ports, prior to actually invoking each port's
I do not have code in hand for this sort of change, but I believe it
should be reasonably easy to hack together, and I'd be happy to put
such such patches together, upon request, if whoever responds to this
PR can't immediately figure out how to do this.
How-To-Repeat: % setenv POSIXLY_CORRECT 1
% portupgrade net/avahi-app
This is a feature request; it needs someone to take an interest
in coding up some patches for testing.
*** Bug 182909 has been marked as a duplicate of this bug. ***
Err, which feedback was needed here? The problem is clear: building packages from ports is not reproducible because the build is highly subject to the user's environment configuration. The solution is of course not so simple, but why close this bug?
(Reopening to ensure this gets seen.)
So, this has been sitting for 6 years, nobody provided a patch, nobody even commented saying "hey, this is important", so nobody cares.
If *you* care, please, provide a patch so that this can get fixed, if you don't, it will stay open until the end of times.
Well, the duplicate bug filed over 2 years ago counts as "hey, this is important", doesn't it? (I know, I know, 2-3 years is _also_ a long time!)
Regardless: I think that having ports builds depend on the environment is particularly bad. Builds should be reproducible, and the fact that the ports tree does not attempt to sanitize the environment goes against this. Builds can fail mysteriously depending on what the user had in his environment, so I think addressing this problem will reduce support requests and make things more predictable.
Last time I looked, clearing the bunch of variables that have most chances of adversely affecting the build should be easy, but going the blacklist route is suboptimal because surely some will be missed. Turning this into a whitelist of variables to use, or making ports completely ignore the user's environment, is probably better but requires more work.
FTR, pkgsrc implements a blacklist. Not perfect, but seems to have worked reasonably well so far.
I personally can't do the changes and verify that they work properly for the whole ports tree...
I sincerly regret that I have been unable to provide a patch since the time that I had originally submitted this PR. And in fact, contrary to my original optimism, I am unsure now even how some kind of proper fix for this issue would be implemented.
I will say however that a simple googling of "clear all environment variables" yields many relevant results. I would like to believe that various steps to do this exact thing could be somehow integrated into the standardized port build process, i.e. so that the environment could be fully cleared at the outset of any port build, however due to other commitments, I personally am unable to work on this small project at this time.