Closed autumnjolitz closed 8 years ago
It builds fine in clean environment, e.g. using ports-mgmt/synth or ports-mgmt/poudriere. I highly recommend you try synth (version 0.98_5), which was created specifically because of reports like this. (in other words, reports that something that doesn't build using raw ports which builds fine in clean environement). The idea being that now synth exists, these reports can be discarded.
FYI, if the dport exists, it builds officially. There are no dports that don't build. It's the definition. bad ports are actively removed.
I gave up and installed the pkg version.
Before encountering these issues, I had done a git pull
on the /usr/dports directory.
I am uncertain how to better communicate my build environment, other than numerous cyclical dependencies were encountered and that I broke those cycles by installing the binary versions.
I did enable the Experimental modules, FAM support, CUPS support (all features except extended attribute support).
If this experience has taught me anything, it is that there is no existing debugging procedure that I can follow that would accurately allow for bug fixing.
However, existence of this issue on a dragonfly host that is very rarely touched (except to configure openldap) is worrisome. It may indicate an out-of-date install or a partial install, neither which I know how to easily resolve.
you've listed several reasons why you should only be using poudriere or synth. The stuff you are describing doesn't happen with those tools.
Either use only pre-built binaries or build everything from src, but mixing the two is a recipe for disaster. Why? Because most people do what you are doing, and only partially update what is needed (without realizing it) and then stuff breaks similarly to what you've described.
Yours is the use case for synth, so if you need ports built with non-standard options, I'd move the synth exclusively.
"I am uncertain how to better communicate my build environment, " By the way, that's the point. "your build environment" is unwanted and assumed dirty and corrupt. errors in your build environment are thus discarded. When you can reproduce in a standard environment, such as synth's, then we can compare. Until then, it's a wild goose chase because normally people have messed up their system (again, without realizing it)
I should address this too: "I did enable the Experimental modules, FAM support, CUPS support (all features except extended attribute support). If this experience has taught me anything, it is that there is no existing debugging procedure that I can follow that would accurately allow for bug fixing."
1) you should understand that no build testing is done on non-default options. There is no guarantee that a port will build if you change an option 2) there is no run-testing done. Only build testing (and only on default options) 3) there could be cyclic dependencies in theory, but that is not a dports problem, it's a freebsd ports problem.
So there's a bit of assumed risk that comes with using customized options, you should realize and accept that as a price for customizing packages.
It looks like Samba is taking some of the system gssapi includes and mixing it with some of it's own gssapi includes via it's include heimdal package.