PATH=/usr/local/bin:/bin:/usr/bin considered harmful

Reindl Harald h.reindl at thelounge.net
Fri Jun 22 11:36:22 UTC 2012



Am 22.06.2012 13:26, schrieb Andrew Haley:
> On 06/22/2012 12:10 PM, Reindl Harald wrote:
>>
>> Am 22.06.2012 13:07, schrieb Andrew Haley:
>>> On 06/22/2012 11:44 AM, Sam Varshavchik wrote:
>>>> Andrew Haley writes:
>>>>
>>>>> On 06/22/2012 04:15 AM, Sam Varshavchik wrote:
>>>>>> 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.
>>>>>
>>>>> What exactly is the conflict?
>>>>
>>>> See the error from yum/rpm, that I posted.
>>>
>>> Oh, sorry, I tend to interpret "conflict" as meaning a conflict with another file, not a missing dependency.
>>>
>>> It seems to me that yum/rpm should know what package provides /bin/perl.  This surely makes vastly more sense than changing default paths, which is just papering over the cracks
>>
>> since /bin and /sbin are now gone it is completly wrong have them in the PATH and use them hardcoded in packages like GLIBC as also in any other package with "Provides"
> 
> But we can't prevent them from being in the PATH, can we?  All sorts
> of upstream packages might hard-code /bin:/usr/bin

but that is no reason to have it in PATH
/bin/bash is the because /bin symlinked to /usr/bin
so any call with full qualified path is still alive

and that is why there is no reason to use /bin and /sbin in
Fedora apckages any longer because it has only the potential
for conflicts like show in this thread

samba was one example correctly referring to /usr/sbin/ldconfig
a glibc update at the same time as a samba update collided
because glibc provides /sbin/ldconfig - RPM is satisfied as
long not both packages are updated at the same time because
for a stat call both exists

having this in mind you see the matrix of potential problems
over the long - "/usr/sbin/ldconfig" is the physical location
after UsrMove and so all fedora packages should use this
and not the symlink-path or mixing what is the worst case
and currently happening

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120622/24d89df5/attachment.sig>


More information about the devel mailing list