olli hauer wrote:
The point is at the moment the port is uninstalled the port has no knowledge
about the reason (uninstall permanent / reinstall / upgrade ) so the assumption
is permanent.
What I really don't get is users complaining about critical machines, special
workflow and then thy do builds on that *critical* system with a script that can be
interrupted by< fill in several reasons>.
You totally missed the point. I didn't talk about critical machines, but
about ports infrastructure doing wrong things. It doesn't matter if it
is some home machine or some supercritical server in datacenter. The
point is that port modifies configuration in a wrong way.
Have you ever thought about a tinderbox, poudriere or simmilar which builds
customized packages all the time in a clean environment?
If the build is finished you have all the sort of buildlogs and can do an
package upgrade in seconds on a prod machine ( it takes me 10min to update a
hand full of machines ).
Did you tried installing / deinstalling mod_xsendfile from package
instead of these empty words?
The behavior is very similar to installation from ports.
Tinderbox, pourdrier or anything else doesn't change what I am talking
about.
It always ends with modified (non-working) httpd.conf.
After the upgrade all I have to do is for services like apache an "svn diff" and maybe an
"svn revert httpd.conf" then fire my daemon_restart scrip and go to the next machine.
So you are recommending home-grown tools to fix ports / packages wrong
behavior. Really "nice" solution!
Miroslav Lachman
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
