Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Am 22.06.2012 14:45, schrieb Sam Varshavchik: Well, yeah. But the Law of unintended consequences applies and that is why i cried out loud that the UsrMove has zero benfits in the real world and crying for troubles long ago before F17 was GA so we must be careful FESCo should HAVE BEEN and should be more careful by approve features I don't think that people expected symlinking /usr/bin to /bin to be risky either nobody linked /usr/bin to /bin the opposite happended [harry@srv-rhsoft:~]$ stat /bin Datei: „/bin“ - „usr/bin“ Errr… Wait. Then UsrMove script that ran when I upgraded F16 to F17 symlinked /bin → usr/bin If new F17 installs have /usr/bin → /bin, then this is an even bigger clusterfrak. If that's the case, bash should be left alone, as doing that is going to break all the new installs. they do not the problems we now have are the usual ones the new features was not implemneted carefully because nobody knows how often absolute paths were used all over the years in SPEC-files, patches, sources and the UsrMove was done not careful enough upgrade survived and now we will see problem after problem becasue things containing one time /usr/bin and one time /bin and the result of yum update sis simplay RANDOM and LUCK i noticed this TWO times wit the same package combination samba / glibc you could update both with each koji-version alone but you ran in trouble update them both at the same time https://bugzilla.redhat.com/show_bug.cgi?id=834209 https://bugzilla.redhat.com/show_bug.cgi?id=829197 the reason for this problem is simply that /usr/sbin/ldconfig in samba-packages is simp,ly correct after UsrMove and glibc still provies /sbin/ldconfig which is a MAJOR BUG looking how a critical thing glibc is for not dealing correct with UsrMove signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On Fri, 22 Jun 2012 18:16:03 -0400, Sam Varshavchik wrote: Michael Schwendt writes: # whereis ldconfig ldconfig: /sbin/ldconfig /usr/sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz /sbin is before /usr/sbin in $PATH. Only for root. And not affecting whereis but only which: $ whereis ldconfig ldconfig: /sbin/ldconfig /usr/sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz $ echo $PATH /usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/ms17b/bin/:/home/ms17b/files/bin $ which ldconfig /usr/sbin/ldconfig Yes, that's fragile and dangerous. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.3-1.fc17.x86_64 loadavg: 0.69 0.64 0.43 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On 06/22/2012 05:15 AM, Sam Varshavchik wrote: [root@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. The path above is used by bash only if PATH env variable is not set. RR -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Roman Rakus writes: On 06/22/2012 05:15 AM, Sam Varshavchik wrote: [root@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. The path above is used by bash only if PATH env variable is not set. Well, yes. Which means that in order to build packages containing portable config code that searches its PATH to locate where the platform installs Perl, and you actually want to be able to avoid your package creating a dependency fail the next time Perl gets upgraded, it is now necessary to override PATH in the rpm spec script. That certainly makes a lot of sense. Not. pgp8dNv3CfJFO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
These search path problems seem to be cropping up in lots of packages. Here's another example: https://bugzilla.redhat.com/show_bug.cgi?id=797557 GPRbuild is designed to be relocatable, because the corporations that are Adacore's customers want to be able to drop a directory tree with binaries and data in some nonstandard directory and use it from there witout recompiling anything. Therefore GPRbuild doesn't have an installation prefix compiled in. Instead it searches for itself on the search path to find out where it is installed. When it finds itself in /bin it concludes that the installation prefix is /, and looks for its data in /share instead of /usr/share, which of course fails because there is no /share. Working around this required a Fedora-specific patch to make GPRbuild resolve the symbolic link. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
2012/6/22 Sam Varshavchik mr...@courier-mta.com: I think that bash needs to be recompiled, with the last two flipped, in the default shell PATH. I have hit a similar issue with the tor-arm package. It is executed by a wrapper script that check if it has been called with /usr/bin/arm, but because the path ordering, it was called with /bin/arm, which failed. I think we should change tha default PATH and put /usr/bin before /bin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On 22 June 2012 09:39, Juan Orti Alcaine j.orti.alca...@gmail.com wrote: 2012/6/22 Sam Varshavchik mr...@courier-mta.com: I think that bash needs to be recompiled, with the last two flipped, in the default shell PATH. I have hit a similar issue with the tor-arm package. It is executed by a wrapper script that check if it has been called with /usr/bin/arm, but because the path ordering, it was called with /bin/arm, which failed. I think we should change tha default PATH and put /usr/bin before /bin I assume this error is also an instance of the same problem: Error: Package: 2:samba-common-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found Error: Package: 2:libsmbclient-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found ? MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On Fri, 22 Jun 2012 09:50:25 +0100, Mary Ellen Foster wrote: I assume this error is also an instance of the same problem: Error: Package: 2:samba-common-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found Error: Package: 2:libsmbclient-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found ? No, that was due to hardcoded /usr/sbin/ldconfig paths: http://pkgs.fedoraproject.org/gitweb/?p=samba.git;a=commitdiff;h=d8012a4f30768375858ab44ec53866fc5c3f9713 and there's a newer update in bodhi already which fixes it. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.3-1.fc17.x86_64 loadavg: 0.41 0.19 0.10 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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. pgp6O0C60FT1r.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Michael Schwendt writes: On Fri, 22 Jun 2012 09:50:25 +0100, Mary Ellen Foster wrote: I assume this error is also an instance of the same problem: Error: Package: 2:samba-common-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found Error: Package: 2:libsmbclient-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found ? No, that was due to hardcoded /usr/sbin/ldconfig paths: Oh, yes it is the same problem, but in reverse. Anyone who searches PATH will find /usr/sbin/ldconfig. glibc rpm installs /sbin/ldconfig. Anything that uses PATH to find ldconfig, and uses it in any way that gets sniffed out by find-requires, is going to cause a conflict with the next glibc update. The package will install fine, but everything will come crashing down, as soon as a mid-release glibc update shows up. The only reason everything hasn't come apart, by now, is because everyone's been hardcoding /sbin/ldconfig in their %post-s and %postun-s. pgpeY5at3tLfj.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 surelay makes vastly more sense than changig default paths, which is just papering over the cracks. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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 Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? this is a bug because incomplete UsrMove Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Andrew Haley writes: Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? I would expect that changing rpm will be a long, tedious process. Which is understandable. But changing the default PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. pgphDZaYbjazl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On 06/22/2012 01:19 PM, Sam Varshavchik wrote: Andrew Haley writes: Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? I would expect that changing rpm will be a long, tedious process. Which is understandable. But changing the default PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. Well, yeah. But the Law of unintended consequences applies, so we must be careful. I don't think that people expected symlinking /usr/bin to /bin to be risky either. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Andrew Haley writes: On 06/22/2012 01:19 PM, Sam Varshavchik wrote: Andrew Haley writes: Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? I would expect that changing rpm will be a long, tedious process. Which is understandable. But changing the default PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. Well, yeah. But the Law of unintended consequences applies, so we must be careful. I don't think that people expected symlinking /usr/bin to /bin to be risky either. Errr… Wait. Then UsrMove script that ran when I upgraded F16 to F17 symlinked /bin → usr/bin If new F17 installs have /usr/bin → /bin, then this is an even bigger clusterfrak. If that's the case, bash should be left alone, as doing that is going to break all the new installs. pgp2xZnwimq0U.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On 06/22/2012 01:45 PM, Sam Varshavchik wrote: Andrew Haley writes: On 06/22/2012 01:19 PM, Sam Varshavchik wrote: Andrew Haley writes: Why not take /bin and /sbin out of the default path *and* make sure that RPM knows about /bin/* ? I would expect that changing rpm will be a long, tedious process. Which is understandable. But changing the default PATH that's compiled into bash should be a simpler change to push through; I see very low risk of any breakage or regressions; and it will probably solve a great majority of the resulting foobarage that cascades downstream into rpm-land. Making rpm a bit smarter is certainly a correct fix, but something else can also be done relatively quickly to take care of most of the current fallout. Well, yeah. But the Law of unintended consequences applies, so we must be careful. I don't think that people expected symlinking /usr/bin to /bin to be risky either. Errr… Wait. Then UsrMove script that ran when I upgraded F16 to F17 symlinked /bin → usr/bin If new F17 installs have /usr/bin → /bin, then this is an even bigger clusterfrak. It doesn't. Don't worry. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On Fri, 22 Jun 2012 06:53:09 -0400, Sam Varshavchik wrote: Michael Schwendt writes: On Fri, 22 Jun 2012 09:50:25 +0100, Mary Ellen Foster wrote: I assume this error is also an instance of the same problem: Error: Package: 2:samba-common-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found Error: Package: 2:libsmbclient-3.6.5-89.fc17.1.x86_64 (@updates-testing) Requires: /usr/sbin/ldconfig Removing: glibc-2.15-37.fc17.i686 (@fedora) Not found Updated By: glibc-2.15-48.fc17.i686 (updates-testing) Not found ? No, that was due to hardcoded /usr/sbin/ldconfig paths: Oh, yes it is the same problem, but in reverse. Anyone who searches PATH will find /usr/sbin/ldconfig. # whereis ldconfig ldconfig: /sbin/ldconfig /usr/sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz /sbin is before /usr/sbin in $PATH. Even if the packager really ran which ldconfig or similar, having forgotten that it's /sbin/ldconfig for years, the result on Fedora 17 would have been /sbin/ldconfig. The following commit Fix usrmove paths. (also see bug 829197) http://pkgs.fedoraproject.org/gitweb/?p=samba.git;a=commitdiff;h=3638a0bfcbbf10e73017dd271e683cce7c13a202 assumed that lots of executables had moved from /bin and /sbin to /usr/bin and /usr/sbin, which is not true for glibc's ldconfig yet. glibc rpm installs /sbin/ldconfig. Anything that uses PATH to find ldconfig, and uses it in any way that gets sniffed out by find-requires, is going to cause a conflict with the next glibc update. The package will install fine, but everything will come crashing down, as soon as a mid-release glibc update shows up. By definition, a conflict is something entirely different. What you describe is a dependency issue, a weak/unsafe dependency, not a conflict. The only reason everything hasn't come apart, by now, is because everyone's been hardcoding /sbin/ldconfig in their %post-s and %postun-s. This is about Fedora 17, not Rawhide. Admittedly, # ll /usr/sbin/ldconfig -rwxr-xr-x. 1 root root 948296 May 11 05:28 /usr/sbin/ldconfig can be misleading, but that is due to the /sbin - usr/sbin symlink, not $PATH. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.3-1.fc17.x86_64 loadavg: 0.39 0.66 0.71 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
A similar issue is that whenever anyone uses AC_PATH_PROG or related in a configure script anywhere, it finds the /bin binary ahead of /usr/bin. You get odd-looking output from ./configure, and perhaps other problems too (though I haven't seen any specifically). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
On Fri, Jun 22, 2012 at 03:08:05PM +0100, Richard W.M. Jones wrote: A similar issue is that whenever anyone uses AC_PATH_PROG or related in a configure script anywhere, it finds the /bin binary ahead of /usr/bin. Maybe I mean this the other way around. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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@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@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@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@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PATH=/usr/local/bin:/bin:/usr/bin considered harmful
Michael Schwendt writes: # whereis ldconfig ldconfig: /sbin/ldconfig /usr/sbin/ldconfig /usr/share/man/man8/ldconfig.8.gz /sbin is before /usr/sbin in $PATH. Only for root. rpm stuff does not get built as root. pgp3Q8qbqlldX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PATH=/usr/local/bin:/bin:/usr/bin considered harmful
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@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@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@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@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. pgpsR2V1ZyN5h.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
