On Fri, 2007-Jan-05 22:01:32 +0000, Nick Hilliard wrote: >>However, the freebsd ports system manages upgrades by removing the old >>package, installing the new one, and hoping that the package itself can >>deal with any sql / config upgrades which might be necessary. ... >>So as maintainer, I'm left with a situation where if a random freebsd >>punter runs "portupgrade" on their sugarcrm installation, they will nuke >> their CRM database. Not optimal. And there is no way in FreeBSD ports >> to detect if the user is running the "portupgrade" command and to bring >> the system to a screeching halt if they try to upgrade sugarcrm by >>using this command.
Note that it's not just portupgrade - any similar ports management tool will run into the same problem. And it's not just an issue for sugarCRM - other ports with database backends have similar issues (even portupgrade has been known to upgrade itself into a state where it can't read its own database). The easiest solution I see is for more of the upgrading smarts to move into the core ports system: Add a new "make upgrade" target which defaults to "make uninstall && make install" but can be over-ridden by ports to suit themselves. -- Peter Jeremy
pgpjSaneI7YQn.pgp
Description: PGP signature
