On Fri, Sep 18, 2009 at 1:19 AM, Blair Zajac <[email protected]> wrote:
> > On Sep 17, 2009, at 11:09 PM, Mark A. Miller wrote: > > On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac <[email protected]> wrote: >> But if I want the port, I want the port. What's the point of installing >> it if you don't want it as the default. >> >> That doesn't particularly make any sense. I can install python26 and >> python31, but I still want python26 to be the default, but be able to use >> python31 if I want to. >> > > Installing these as the default doesn't stop you from using /usr/bin tools > when you want to, just as installing python26 as the default doesn't stop > you from using python31 if you want to. > Okay? I was answering your question of why I'd want to install something if I didn't want it as the default. Another example, and pointedly related, I want GNU sed for certain purposes, but I don't want it to be the default, because I want BSD sed for other purposes. > As for building ports, then we set the port to use /usr/bin/sed and not >> $prefix/bin/sed for the few cases that are different. >> >> Right, and for the thousands and thousands of lines of Makefiles for the >> many packages that either ignore documented ./configure variables, use them >> in some places but not in others, fetches the needed utility out of your >> $PATH of the executing shell, or are hardcoded, not to mention the large >> amount of portfiles and patches that would need to be modified...no, that >> idea makes no sense whatsoever. >> > > I understand what you're trying to say, but I don't think you realize the >> vast ramifications of it. >> > > I think you're mistaken there. Not particularly. I've done a lot of cross-compiling and porting, and dealing with Makefile idiocy. > I've installed many ports with coreutils, findutils and other ones > installed and the only issue I've ever run into was with an issue of the > python* ports installing using xargs. > > I'm not suggesting doing this for all ports, just where there's breakage. It's still more work than just allowing the GNU utilities to live in something like ${prefix}/libexec/gnubin. And probably most of the tools you had installed, most of the commands are specified in SuSV4/5, so BSD/GNU had the same functionality. I noticed you didn't mention sed, though. Basically what you're suggesting would cause MacPorts to maintain patches that would distinctly not be merged upstream. I just don't understand why you want more work and breakage. Also, a critical thing to note, is that utilities and such outside of MacPorts would potentially break if they reference something such as sed from the $PATH, so your solution would break things which we have no control over. Whereas by default installing things with a "g" prefix, and having a variant to put them in ${prefix}/libexec/gnubin, and the user must manually add that to their $PATH. So it doesn't break for the general user if they install these things, and lets the "People who know what they're doing" nicely add the GNU utilities as their standard name to their $PATH for certain things. > Blair -- Mark A. Miller [email protected]
_______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
