Remove +with_default_names and use a specific path for unprefixed binaries

[Mark A. Miller]

On Fri, Sep 18, 2009 at 1:19 AM, Blair Zajac <blair at orcaware.com> wrote:

>
> On Sep 17, 2009, at 11:09 PM, Mark A. Miller wrote:
>
> On Fri, Sep 18, 2009 at 1:04 AM, Blair Zajac <blair at orcaware.com> 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
mark at mirell.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090918/f5c3ceb5/attachment.html>