Hi, I've just upgraded my Linux adaptation of MacPorts's master branch, where I was helped greatly by the fact I use the system package manager (after doing a -reinstated- `port dpkg MacPorts-devel`) because it allowed me to revert to the previous version when I ran into a glitch I had introduced myself. Yes, I use port:MacPorts-devel as a tool to benefit from reproducible builds and easy patch management. Works great despite someone once telling me that "base" isn't meant for that :)
1) This led me to wonder how many files I have left over from previous `make install` type upgrades on Mac, and if using packages created by `port pkg MacPorts-devel` is an answer to that question (as well as to being able to revert to the previous version in case you mess something up). 2) I seem to remember that we discussed port:MacPorts and/or port:MacPorts-devel years ago and that there were plans to make it possible to let MacPorts control its own. I don't know if I just dreamt it or if such plans were abandoned ... but exactly what is/was the problem with actually installing port:MacPorts? The fact that you can uninstall the port and be left with a broken install (which you can simply avoid doing) or the fact that this will also happen "behind the scenes" when you do an upgrade (or de/activate) because all required files aren't read into memory before doing the upgrade (or de/activate)? In case answers to both 1) and 2) are negative: it should be possible for someone to roll their own package/version management by installing port:dpkg, port:rpm or whatever other simpler alternatives exist. If any of those actually work reliably on Mac? FWIW, I have a custom port for `porg` (http://porg.sourceforge.net/) but I have never actually checked if it is clever enough to uninstall stale files from a previous package version. Thanks, R. PS: all this is provoked by my recent tweaks to the buildsystem making it possible to build "base" with link-time optimisation, which was an interesting exercise in itself, exposing a few more false-positive design flaws in autoconf :)
