PATH=/usr/local/bin:/bin:/usr/bin considered harmful
John Ellson
john.ellson at comcast.net
Fri Jun 22 14:28:52 UTC 2012
> Having thought about it, I don't think it's unreasonable to do a
"which $PROG", and stick it into the hashbang. I think that's a
perfectly reasonable approach, with portability being the goal. The
problem I see here, is > that Fedora's bash is compiled with the default
PATH placing a symlink, /bin, ahead of /usr/bin, in the PATH list:
+1 on this.
This has very little to do with yum; It affects other programs too.
It breaks graphviz builds, for example, because
its build scripts try to deduce various tcl paths from `which tclsh`
It is also a significant performance hit for every executable lookup to
traverse an extra softlink from /bin -> /usr/bin.
Since there is nothing in /bin now, /bin should be after /usr/bin in the
default PATH..
John
On 06/21/2012 11:15 PM, Sam Varshavchik wrote:
> The perl update that hit updates this week is causing a yum conflict
> with some locally-built packages, of this type:
>
> Error: Package: courier-imap-4.10.0.20120202-2.17.x86_64 (installed)
> Requires: /bin/perl
> Removing: 4:perl-5.14.2-211.fc17.x86_64 (@anaconda-0)
> Not found
> Updated By: 4:perl-5.14.2-212.fc17.x86_64
> (updates-released-local)
> Not found
>
>> From what I can tell, the sequence of events is:
>
> A) A local package's configure script executes "which perl", and puts
> that into each perl script's hashbang. So:
>
> [root at octopus ~]# which perl
> /bin/perl
>
> This results in:
>
> #! /bin/perl
>
> B) The rpm package gets built. find-requires that puts this dependency
> into the package:
>
> requires=/bin/perl
>
> C) At install time, rpm seems to be smart to figure this out:
>
> [root at octopus ~]# rpm -q --whatprovides /bin/perl
> perl-5.14.2-211.fc17.x86_64
>
> It's smart enough sees that thanks to the symlinks,
> /bin/perl=/usr/bin/perl. So the package gets installed, with these
> hashbangs.
>
> D) A perl update hits:
>
> [root at shorty x86_64]# rpm -q -l -p perl-5.14.2-212.fc17.x86_64.rpm |
> fgrep bin/perl
> /usr/bin/perl
> /usr/bin/perl5.14.2
> /usr/bin/perlbug
> /usr/bin/perlthanks
>
> The new perl package contains /usr/bin/perl. At upgrade, dependency
> resolution is not smart enough to realize that the new package's
> /bin/perl=/usr/bin/perl, causing a conflict.
>
> Having thought about it, I don't think it's unreasonable to do a
> "which $PROG", and stick it into the hashbang. I think that's a
> perfectly reasonable approach, with portability being the goal. The
> problem I see here, is that Fedora's bash is compiled with the default
> PATH placing a symlink, /bin, ahead of /usr/bin, in the PATH list:
>
> [root at octopus ~]# strings /bin/bash | grep usr.bin
> /usr/local/bin:/bin:/usr/bin
>
> I think that bash needs to be recompiled, with the last two flipped,
> in the default shell PATH.
>
> Until then, I need to hack each one of my locally-built package's rpm
> spec scripts, and manually prepend /usr/bin to the PATH. Which sucks.
>
>
>
>
More information about the devel
mailing list