Jordan K. Hubbard wrote:
I'm not going so far as to suggest that dependencies should be limited to items in the Depot, and I definitely see the value of being able to link with components of the OS which would be painful to duplicate (all of X11 comes to mind) or have been specifically optimized so as to make them more attractive than the MacPorts- provided ones. What I'm saying is that for the MacPorts-provided dependencies, being able to force them into the depot and out of / opt/local would allow a lot more things to coexist simultaneously.
It would also make the "images" actually do something except just clutter up the disk and mess with upgrades (activity state not checked, inactive ports filling dependencies, etc), like they do now. For instance there's a linux distribution called GoboLinux that uses multiple "images".
http://www.netbsd.org/gallery/pkgsrc-interviews.html#gobo-linux
As MacPorts grows into a real collection (4,622 ports may seem a lot, but it's nothing close to FreeBSD's 18,280), this will become a larger and larger problem. FreeBSD "solves" it by doing namespace munging for every port that conflicts (/usr/local/bin/ foo-5.6.2, /usr/lib/libfoo.5.6.2.so, /usr/include/foo-5.6.2 and so on), which is about as much work as forcing things into the depot without the benefits of having an "uncluttered" /usr/local by default.
MacPorts already does this too... For instance Python doesn't install as "python", but as "python2.4" and "python2.5" etc (meaning that all shebangs needs changing). And Apache installs into either /opt/local or /opt/local/apache2, so that you can run both Apache 1.3 and Apache 2.2 at once.
It's very ad-hoc, and tough on both packagers and users... --anders _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
