On Oct 19, 2011, at 15:43, Michael O'Brien wrote: > On Oct 18, 2011, at 4:03 PM, Ryan Schmidt wrote: > >> We would appreciate it if you would not increase our future support >> workload, and pick a different prefix for your binaries, such as >> /opt/yourpackage or /usr/local/yourpackage. That is: install a fresh >> MacPorts, built from source, with "./configure --prefix=whatever". Then >> build your packages using that MacPorts. I would not anticipate that you >> would run into any problems by doing so. > > The package has already been deployed, so that horse has left the barn.
You can always release an update. > Installation of MacPorts should, as I understand it, be stone ignorant of > existing packages installed sans MacPorts; they're not in the MacPorts > installed-package DB, assuming it has one. If it doesn't, then oops. Yes, MacPorts is ignorant of things installed without its help. MacPorts also expects to be in more or less complete control of its prefix. So if you install things into its prefix manually, without using MacPorts (i.e. using your package installer), that can cause problems if MacPorts later wants to install those very same files. If your port is not in the official ports tree, and has no dependencies on any ports in the official ports tree, then there shouldn't be a problem. If it does have dependencies on existing ports, and you've distributed an mpkg (meaning it includes those dependencies), then you'll cause a problem like the one described in the ProblemHotlist entry I pointed you to earlier, for users who later decide to install MacPorts and end up installing those same dependencies with it. > Frankly, it's one reason why we'd like an uninstaller. One of the advantages of using MacPorts is that things can be easily uninstalled (with "sudo port uninstall"). Outside of MacPorts, you can either rely on a 3rd-party uninstaller to handle reading your receipt properly, or you can write your own uninstallation script and distribute it with your software. But this would be an opportunity to improve our package creation code: since MacPorts already knows what files it's putting into a package, it could easily write a script that removes them, and install that script as well. We'd just need to decide where the script should be installed. _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
