Re: still UsrMove problems and wrong PATH in openssh
Björn Persson (bjorn@rombobjörn.se) said: Emmanuel Seyman wrote: From bug #871503 (and I apologize if I'm reading this wrong), it appears that the dependency on /bin/perl is being caused by the hardcoded $PATH in openssh. To fix the problem, I think we would not only need to provide /bin/perl but a /bin equivalent to everything in /usr/bin (/bin/perl is the only usecase which Harald has hit so far). That still wouldn't solve all cases. I've seen code that does the equivalent of which some-program, finds /bin/some-program, concludes that the installation prefix is /, and proceeds to look for files in /share, which doesn't exist and never has. We really need to get /bin and /sbin removed from PATH, or at least moved behind /usr/bin and /usr/sbin. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
still UsrMove problems and wrong PATH in openssh
it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with rpmbuild having Requires: /bin/perl as example in my opinion rpmbuild should know about the change and fix implicit Requires: /bin and Requires: /sbin https://bugzilla.redhat.com/show_bug.cgi?id=856590 WHY are F18 packages built for testing if a bugreport is for F17 - if someone is working hard to get F17 running as F16 before this is not helpful https://bugzilla.redhat.com/show_bug.cgi?id=871503 https://bugzilla.redhat.com/show_bug.cgi?id=856590 https://bugzilla.redhat.com/show_bug.cgi?id=856584 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On 10/31/2012 10:47 AM, Reindl Harald wrote: it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with rpmbuild having Requires: /bin/perl as example in my opinion rpmbuild should know about the change and fix implicit Requires: /bin and Requires: /sbin rpmbuild could have tried realpath first: # rpm -ql perl | grep -E '^/bin/perl' # realpath /bin/perl /usr/bin/perl # rpm -ql perl | grep -E '^/usr/bin/perl' /usr/bin/perl /usr/bin/perl5.16.1 /usr/bin/perlbug /usr/bin/perlthanks https://bugzilla.redhat.com/show_bug.cgi?id=856590 WHY are F18 packages built for testing if a bugreport is for F17 - if someone is working hard to get F17 running as F16 before this is not helpful I usually try to fix bugs in latest versions and then backport fixes back to older releases. In this case, the bug was accidentally closed by F18 update and since it's closed it went out of my sight. Also I missed you comment. I'm sorry. Feel free to reopen a bug if you think that an issue is not fixed. Here's an update https://admin.fedoraproject.org/updates/openssh-5.9p1-27.fc17 petr -- Petr Lautrbach, Red Hat, Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On 10/31/2012 11:47 AM, Reindl Harald wrote: it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with rpmbuild having Requires: /bin/perl as example in my opinion rpmbuild should know about the change and fix implicit Requires: /bin and Requires: /sbin But they're not implicit. As I've said in the bug(s) already, rpm doesn't invent paths, it generates dependencies based on the file contents: if a script has #!/bin/perl through whatever means (ie hardcoded or generated), /bin/perl is what you get as a dependency. And rpm can't do the damnest thing about it: it doesn't know whether some arbitrary path is intentional or not, it doesn't know what distro you're actually building a package for, AND trying to fix paths with eg realpath() would result in all sorts of other breakage: eg /sbin/ldconfig is what glibc provides, not /usr/sbin/ldconfig. As also said in one of the bugs: the simple solution is to fix your build environment. You dont even need the openssh fix for that. Rpm builds are only reproducible given identical environment, and there are countless things that can differ between personal accounts on different hosts, the best way to ensure sane build environment in Fedora-land is to build the packages in mock. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Am 31.10.2012 17:45, schrieb Panu Matilainen: On 10/31/2012 11:47 AM, Reindl Harald wrote: it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with rpmbuild having Requires: /bin/perl as example in my opinion rpmbuild should know about the change and fix implicit Requires: /bin and Requires: /sbin But they're not implicit. As I've said in the bug(s) already, rpm doesn't invent paths, it generates dependencies based on the file contents: if a script has #!/bin/perl through whatever means (ie hardcoded or generated), /bin/perl is what you get as a dependency this is WRONG behavior any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove UsrMove is a distribution-feature and so the distribution has to care that basic parts of the ditsribution do the rights things CENTRALIZED signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On Wed, Oct 31, 2012 at 1:33 PM, Reindl Harald h.rei...@thelounge.netwrote: this is WRONG behavior any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove UsrMove is a distribution-feature and so the distribution has to care that basic parts of the ditsribution do the rights things CENTRALIZED I'm not a Perl programmer... but shouldn't scripts be using something like #!/usr/bin/env perl rather than hardcoding #!/bin/perl anyway? That's the way Python scripts have been written for years (#!/usr/bin/env python), long before UsrMove. Patching scripts to use the env-style crunchbang makes sense for more reasons then just supporting UsrMove- it would make them more portable in general- so I don't really see why this would be an idiotic idea. Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On Wed, Oct 31, 2012 at 03:21:56PM -0400, Ben Rosser wrote: I'm not a Perl programmer... but shouldn't scripts be using something like #!/usr/bin/env perl rather than hardcoding #!/bin/perl anyway? That's the way Python scripts have been written for years (#!/usr/bin/env python), long before UsrMove. Well, /bin/perl would immediately fail on Debian or Ubuntu, so it seems pretty unlikely that any upstream is doing it. There are reasons why using env can be a bad idea and I don't think it's universal, but /bin/perl is certainly wrong. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On Wed, Oct 31, 2012 at 06:33:10PM +0100, Reindl Harald wrote: Am 31.10.2012 17:45, schrieb Panu Matilainen: On 10/31/2012 11:47 AM, Reindl Harald wrote: it is REALLY bad make UsrMove and HRADCODE /bin:/sbin in PATH of openssh, this results in packages built with rpmbuild having Requires: /bin/perl as example in my opinion rpmbuild should know about the change and fix implicit Requires: /bin and Requires: /sbin But they're not implicit. As I've said in the bug(s) already, rpm doesn't invent paths, it generates dependencies based on the file contents: if a script has #!/bin/perl through whatever means (ie hardcoded or generated), /bin/perl is what you get as a dependency this is WRONG behavior This does not necessarily follow from: any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove UsrMove is a distribution-feature and so the distribution has to care that basic parts of the ditsribution do the rights things CENTRALIZED this. UsrMove was a Fedora specific distribution change. As such, patching of applications to use /usr/bin/perl instead of /bin/perl is a distribution change that we should be making as well. If the people affected by these local patches feel that the cost they have to bear for implementing UsrMove is too much, perhaps they should propose an F19 feature to Move programs and libraries to a more traditional hierarchy Fedora has been known to implement things that were later reverted. -Toshio pgptrsG7uH8Pi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On Wed, Oct 31, 2012 at 03:21:56PM -0400, Ben Rosser wrote: On Wed, Oct 31, 2012 at 1:33 PM, Reindl Harald h.rei...@thelounge.net wrote: this is WRONG behavior any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove UsrMove is a distribution-feature and so the distribution has to care that basic parts of the ditsribution do the rights things CENTRALIZED I'm not a Perl programmer... but shouldn't scripts be using something like #!/ usr/bin/env perl rather than hardcoding #!/bin/perl anyway? That's the way Python scripts have been written for years (#!/usr/bin/env python), long before UsrMove. env comes with its own problems. The one I'm most familiar with is when a site has its own, somewhat incompatible version of the interpreter installed. For instance, if Fedora ships with python == python-2.7 and the site installs /usr?local/bin/python and places that first in the PATH. Sudddenlyy rpm managed packages that use /usr/bin/env python will break. This can also come into play with versions that are closer in nature. For instance, we might install python-2.7.1 via rpm but the site might install python-2.7.2 locally. If the scripts that are installed require python modules, the rpm dependencies will make sure those deps are installed for the system python-2.7.1. But they won't be installed for the local python-2.7.2 version. If that comes first in the PATH and a script uses /usr/bin/env python, this will break as well. -Toshio pgpiHgfzYX7VX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
* Reindl Harald [31/10/2012 22:44] : any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove Historically, we've always patch upstreams that use non-existant-on-Fedora paths (like /bin/perl, /usr/local/bin/python, /opt/bin/ruby, ...) to use the path that exists in Fedora. Treating /bin differently from everything else doesn't sound logical. * Ben Rosser [31/10/2012 22:44] : I'm not a Perl programmer... but shouldn't scripts be using something like #!/usr/bin/env perl rather than hardcoding #!/bin/perl anyway? That's the way Python scripts have been written for years (#!/usr/bin/env python), long before UsrMove. If you're patching the scripts in your package, it make more sense to use the correct path and avoid the performance hit. If you're submitting patches to upstream, they may demand an env-style shebang. * Toshio Kuratomi [31/10/2012 22:44] : UsrMove was a Fedora specific distribution change. As such, patching of applications to use /usr/bin/perl instead of /bin/perl is a distribution change that we should be making as well. From bug #871503 (and I apologize if I'm reading this wrong), it appears that the dependency on /bin/perl is being caused by the hardcoded $PATH in openssh. To fix the problem, I think we would not only need to provide /bin/perl but a /bin equivalent to everything in /usr/bin (/bin/perl is the only usecase which Harald has hit so far). Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Am 31.10.2012 22:35, schrieb Toshio Kuratomi: But they're not implicit. As I've said in the bug(s) already, rpm doesn't invent paths, it generates dependencies based on the file contents: if a script has #!/bin/perl through whatever means (ie hardcoded or generated), /bin/perl is what you get as a dependency this is WRONG behavior This does not necessarily follow from: any upstream-script the next years will use #!/bin/perl and it would be idiotic to write patches for every application only becasue fdora decided to make UsrMove UsrMove is a distribution-feature and so the distribution has to care that basic parts of the ditsribution do the rights things CENTRALIZED this. UsrMove was a Fedora specific distribution change. As such, patching of applications to use /usr/bin/perl instead of /bin/perl is a distribution change that we should be making as well. why patch a unkown count of scrupts instead make sure in the central part rpmbuild that UsrMove is respected If the people affected by these local patches feel that the cost they have to bear for implementing UsrMove is too much, perhaps they should propose an F19 feature to Move programs and libraries to a more traditional hierarchy Fedora has been known to implement things that were later reverted how do you imagine to revert UsrMove? it makes pretty no sense because it is much harder than move the files from /bin and 7sbin to another location and replace the directory with a symlink the problem is that such features with zero benefit are done in a rush - where is the real benefit? cleaner root fs was one of the argumentations - what is cleaner now? the folder count is the same and if it is a physical folder or a link does not matter the argumentation with /usr on a sepearetd fileystem and share it between different os-installations is bull***t as also the argumentation make a snapshot of /usr on a own partition before upgrades and revert because /etc and /var/lib with the rpm-database would not be affected from restore the snapshot and the whole system would be broken after doing so hopefully in the future features are more usefull and the pain-potential would be better considered instead doing changes because we can and waste time which could be used for useful things signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
On Wed, Oct 31, 2012 at 02:48:33PM -0700, Toshio Kuratomi wrote: env comes with its own problems. The one I'm most familiar with is when a site has its own, somewhat incompatible version of the interpreter installed. For instance, if Fedora ships with python == python-2.7 and the site installs /usr?local/bin/python and places that first in the PATH. Sudddenlyy rpm managed packages that use /usr/bin/env python will break. Yeah. The env kludge is great for user-level scripts, but bad for anything packaged with the OS (unless that thing is _meant_ to work with arbitrary versions of the interpreter.) -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Emmanuel Seyman wrote: From bug #871503 (and I apologize if I'm reading this wrong), it appears that the dependency on /bin/perl is being caused by the hardcoded $PATH in openssh. To fix the problem, I think we would not only need to provide /bin/perl but a /bin equivalent to everything in /usr/bin (/bin/perl is the only usecase which Harald has hit so far). That still wouldn't solve all cases. I've seen code that does the equivalent of which some-program, finds /bin/some-program, concludes that the installation prefix is /, and proceeds to look for files in /share, which doesn't exist and never has. We really need to get /bin and /sbin removed from PATH, or at least moved behind /usr/bin and /usr/sbin. Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Well, /bin/perl would immediately fail on Debian or Ubuntu, so it seems pretty unlikely that any upstream is doing it. There are reasons why using env can be a bad idea and I don't think it's universal, but /bin/perl is certainly wrong. /usr/bin/perl is pretty much _the_ path for perl (at least on Unix-like systems that recognize the shebang line). Even if you install it somewhere else, it is highly recommended to create a symlink (and IIRC make install does so unless you override it, or at least used to). Especially for distribution-installed files, running env is not a good idea. In addition to the overhead of execing another binary and searching $PATH, you can easily get a different version of the interpreter that the script is not tested (or even compatible) with when users download source and make install to /usr/local/bin. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: UsrMove was a Fedora specific distribution change. As such, patching of applications to use /usr/bin/perl instead of /bin/perl is a distribution change that we should be making as well. Everything should be using /usr/bin/perl (perl has never AFAIK been in /bin, on any system I've used). The only case I would think /bin/perl would happen is if some software install script tried to be smart and change the shebang line, and it searched in common directories but not in $PATH order (starting with /bin). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still UsrMove problems and wrong PATH in openssh
Am 01.11.2012 00:34, schrieb Chris Adams: Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: UsrMove was a Fedora specific distribution change. As such, patching of applications to use /usr/bin/perl instead of /bin/perl is a distribution change that we should be making as well. Everything should be using /usr/bin/perl (perl has never AFAIK been in /bin, on any system I've used). The only case I would think /bin/perl would happen is if some software install script tried to be smart and change the shebang line, and it searched in common directories but not in $PATH order (starting with /bin) look here: https://bugzilla.redhat.com/show_bug.cgi?id=834571 The DEFAULT_PATH_VALUE in bash (/usr/local/bin:/bin:/usr/bin) is used only if the PATH env variable is not set and WHAT do you think happens after UsrMove if something is tgrying to find a binary in excatly this order? it will find /bin/perl, /bin/php at whetever you can imagine which was not in /bin BEFORE UsrMove was done in THAt is why i called usrMove a really bad idea long before it was approved as feaurure for F17 well, now the damage is done, so REMOVE /bin and /sbin from the WHOLE distribution in ANY path configuration - and this SHOULD have been done BEFORE F17 was released as GA signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
