Conflict Installing py34-setuptools34-5.5.1_1

I'm in the process of installing BIND 10. Over the weekend, I ported and installed Xorg (X11) and Firefox. Xorg installed Python 2.7. Now, BIND 10 looks for Python 3.4. After installing Python 3.4 and setenv PYTHON_DEFAULT 3.4 . . .the BIND10 make stopped at:

Code:
Installing py34-setuptools34-5.5.1_1...
pkg-static: py34-setuptools34-5.5.1_1 conflicts with py27-setuptools27-5.5.1_1
(installs files into the same place).
Problematic file: /usr/local/bin/easy_install
*** Error code 70
What to do? I now have this second version of Python installed. Apparently, the first install of Python 2.7 associated with the install of xorg automagically installed py27. Can I deinstall py27 and install py34? . . .Will Xorg be happy if I deinstall Python2.7, et al. and install the associated versions of *34?
 
Did you install dns/bind10 or dns/bundy? Since ISC doesn't support BIND 10 and the community is taking the reigns of it with Bundy, you may want to start with dns/bundy you you are using something that will be supported over the long term if you need its features. That port may have the same issues, but lets at least get going in the direction we want before spending too much time troubleshooting. Otherwise there is always dns/bind910 without the Python 3.4 requirement and with the continued support of ISC.
 
Did you install dns/bind10 or dns/bundy? Since ISC doesn't support BIND 10 and the community is taking the reigns of it with Bundy, you may want to start with dns/bundy you you are using something that will be supported over the long term if you need its features. That port may have the same issues, but lets at least get going in the direction we want before spending too much time troubleshooting. Otherwise there is always dns/bind910 without the Python 3.4 requirement and with the continued support of ISC.

Thanks for the "heads-up" on the status of the BIND10 port. Actually, I tried the "experiment" that I previously alluded to and deleted Python2.7 . . .really screwed up xorg and FireFox (as expected); regardless, I just finished a reinstall (cleanup) of xorg and FireFox (took about four hours). Your recommendation to use BIND910 was/is already in my plan. I already have configuration files for it, and has been working well for months (actually, I've used BINDn since 2001 . . .? FYI, I have an autographed copy of Cricket Liu's book, DNS with Bind. I attended a luncheon seminar hosted by him, et.al. Super nice guy!).

Regarding BIND10, essentially a "Catch-22". Would be nice to know in advance, as could be noted in the ports notes ;)

Well . . .off to build BIND910.

Thanks again,
 
It's marked as deprecated. You have to be quick... It shows up right as the port starts compiling.

Code:
===>   NOTICE:

This port is deprecated; you may wish to reconsider installing it:

Is not developed any more, use [PORT]dns/bundy[/PORT].

It is scheduled to be removed on or after 2015-12-31.
 
It's marked as deprecated. You have to be quick... It shows up right as the port starts compiling.

Code:
===>   NOTICE:

This port is deprecated; you may wish to reconsider installing it:

Is not developed any more, use [PORT]dns/bundy[/PORT].

It is scheduled to be removed on or after 2015-12-31.

Noted and appreciated. Just finished the build as reported:
Code:
===>  Registering installation for bind910-9.10.2_3

Wow! A lot of water under the bridge since I first started using BIND almost fifteen years ago. (Am I old or what?) Actually, I was running BIND on FreeBSD v4.8 . . .if it ain't broke, don't fix it (don't laugh . . .speaks well for FreeBSD vs. Windows). Had a utility power failure Tuesday morning. The UPS was running down and I started shutting down servers. The v4.8 system didn't shut down as expected . . .seemed to go into a hard wait, so I just punched the "tilt" button. My Bad! It was left with corrupted and unrepairable HD sectors on a secondary HD where /usr lived. Well, time to upgrade, so I downloaded a v10.1 ISO and started from there.
 
Reliability is great. However, an un-maintained or un-patched system is "broken" in a way. Just as I would never go around advertising my car hasn't hasn't blown up yet if I never changed the oil, I wouldn't recommend ignoring the inevitable security issues that are discovered over time. See https://www.freebsd.org/security/advisories.html. Make it about designing in redundancy and maximizing availability of services rather than chasing some magic uptime number and it will be far easier to keep things maintained and secure over time.
 
Back
Top