Ticket #14796 (pike): please commit

[Anders F Björklund]

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