Remove +with_default_names and use a specific path for unprefixed binaries

Mark A. Miller mark at mirell.org
Fri Sep 18 20:20:00 PDT 2009


On Fri, Sep 18, 2009 at 10:06 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On Sep 18, 2009, at 09:58, Mark A. Miller wrote:
>
>  On Fri, Sep 18, 2009 at 6:40 AM, Ryan Schmidt wrote:
>>
>
>  Ah, true, nothing is preventing anyone from making their own symlinks
>>> somewhere. In which case, there isn't even a problem with just removing the
>>> with_default_names variants entirely and not creating a replacement. But it
>>> would be nice to at least symlink them into one directory.
>>>
>>
>> Symlinking doesn't always work. There are some packages (yes, scary
>> enough) that *despite* the fact you have a perfectly fine symlink in a
>> directory for it, try to do something like "stat -L" on the symlink for the
>> utilities path. It's rare, but I've seen it occur. (It's also sick and
>> broken, but what can you do...)
>>
>
> Well, all we're proposing is that the ports should automatically create
> default-named symlinks in ${prefix}/libexec/gnubin to the programs that are
> being installed. So if that doesn't work for what you need, then the
> proposed changes won't help... But I don't see why a program would do a
> "stat -L" on awk or sed or grep...
>

It's rare. But I'll concede on that, it's a very strange corner case. (But
it's always those we remember the best...)

The current with_default_names variants also all just create default-named
> symlinks, though in ${prefix}/bin. And you haven't mentioned that not
> working...
>

I haven't done that because it breaks other things, I just copied the
executables into a separate directory and stripped off their names for my
own purposes.

So, ${prefix}/libexec/gnubin seems to work, and put symlinks there for the
GNU binaries by default, and get rid of this variant?


-- 
Mark A. Miller
mark at mirell.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090918/7e3a27c1/attachment.html>


More information about the macports-dev mailing list