On Apr 30, 2013, at 7:02 PM, Bill Cole <postfixlists-070...@billmail.scconsult.com> wrote:
> Yes, it can. MacPorts creates its own world under /opt/local and uses very > limited parts of of the base system (e.g. the XCode build toolchain) where > necessary. There's no simple way to tell MacPorts that you've installed > dependencies outside of MacPorts that you want it to use instead of its > internal dependencies, but some software (e.g. autoconf scripts and similar > build tools) can sometimes find manually installed stuff in /usr/local and > use it instead of a MacPorts-installed version. Hilarity (or something) > ensues... > > I have found that just using MacPorts where possible instead of maintaining > my own MacOS builds of open source software has been the right choice, > because I really don't get anything out of manually doing the housekeeping > that MacPorts handles for me, and I'm more likely to make a mistake in it > that I will discover because one component breaks when I want it working. Do > I really want to manually keep track of which of the >100 OSS packages I have > installed need rebuilding because I want to fix latest OpenSSL oopsie? No, > not really. If I were starting from scratch, I'd probably go the MacPorts route. But trying to switch a running system is a lot of work. Easier to keep going with what I have. I have a good enough feel for what does what that when something breaks, I usually can deal with it quickly. In fact, on my aborted attempt to upgrade to Mountain Lion (on my "test system" - just my regular MacBook Pro booted off a clone of the server), lots broke. Due to the Postfix issues which I already knew about, I did a MacPorts install of Postfix. But then as I moved on, I found Postfwd wouldn't run as it needed something updated in CPAN. And that's where MacPorts caused me trouble because with the MacPorts changed PATH value, CPAN was updating the MacPorts library, not the one Postfwd was using. >> Just make sure that when you manually build postfix, you don't blindly let >> it link into the base MacOS X world. That can cause trouble (i.e. a need to >> rebuild) after any OS update, major or minor. Apple makes no allowances for >> users replacing base components and will not accommodate your reliance on a >> version of something in /usr/lib/ that they no longer need. I followed the diymacserver.com instructions (mentioned by James Brown in another note although I had already found it) which helped me over a big hurdle which was getting the make makefiles arguments all combined properly. It does dip into /usr/lib for a couple of things - -llber and -lresolv. But the Postfix command, config, and daemon directories are all in /usr/local. The one thing that isn't is sendmail but I have so much (scripts, etc.) that have /usr/sbin/sendmail in them that's it's probably easier to leave that in /usr/sbin, keep a copy, and restore it if Apple wipes it out in an upgrade. Just need to remember to check each time. Anyway, I did a test build and install and all seemed to work as expected with no surprises. But since everything sits behind a NAT router, I have no easy way to route external mail to it. I do have a second IP address I can use so the final test will be to make a good backup, switch the router to the alternate IP address (thereby stopping legitimate outside mail from getting in), install in production, test, and if all seems OK, switch back to the regular IP address. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
