Bug 144533 - [bsd.port.mk] ports tree Makefiles fail to setup a standardardized ENV
Summary: [bsd.port.mk] ports tree Makefiles fail to setup a standardardized ENV
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
: 182909 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-07 20:00 UTC by Ronald F. Guilmette
Modified: 2016-04-14 21:20 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ronald F. Guilmette 2010-03-07 20:00:02 UTC
	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.

Fix: 

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
	own Makefile.

	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
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-03-11 23:48:12 UTC
State Changed
From-To: open->suspended

This is a feature request; it needs someone to take an interest 
in coding up some patches for testing. 


Comment 2 Mark Linimon freebsd_committer freebsd_triage 2010-03-11 23:48:12 UTC
Class Changed
From-To: sw-bug->change-request



Comment 3 Mark Linimon freebsd_committer freebsd_triage 2010-03-11 23:48:12 UTC
Responsible Changed
From-To: freebsd-ports-bugs->portmgr
Comment 4 Mathieu Arnold freebsd_committer 2015-06-14 03:09:22 UTC
*** Bug 182909 has been marked as a duplicate of this bug. ***
Comment 5 Julio Merino,+1 347 694 0576,New York City freebsd_committer 2016-04-13 16:56:26 UTC
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.)
Comment 6 Mathieu Arnold freebsd_committer 2016-04-13 18:31:35 UTC
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.
Comment 7 Julio Merino,+1 347 694 0576,New York City freebsd_committer 2016-04-13 20:59:52 UTC
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...
Comment 8 Ronald F. Guilmette 2016-04-14 21:20:37 UTC
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.