4:47 a.m.
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
11:28 a.m.
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
11:45 a.m.
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 -
12:33 p.m.
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
2:21 p.m.
On Wed, Oct 31, 2012 at 1:33 PM, Reindl Harald <h.reindl(a)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.
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
4:03 p.m.
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 | mjg59(a)srcf.ucam.org
6:31 p.m.
Once upon a time, Matthew Garrett <mjg59(a)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 <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:48 p.m.
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.reindl(a)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
6:05 p.m.
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 ☁☁☁ <mattdm(a)fedoraproject.org>
4:35 p.m.
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
4:43 p.m.
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
5:21 p.m.
* 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
6:18 p.m.
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
12:45 p.m.
Björn Persson (bjorn(a)xn--rombobjrn-67a.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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:34 p.m.
Once upon a time, Toshio Kuratomi <a.badger(a)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 <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:56 p.m.
Am 01.11.2012 00:34, schrieb Chris Adams:
Once upon a time, Toshio Kuratomi <a.badger(a)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
4242
days inactive
4243
days old
15 comments
11 participants
participants (11)
-
Ben Rosser -
Bill Nottingham -
Björn Persson -
Chris Adams -
Emmanuel Seyman -
Matthew Garrett -
Matthew Miller -
Panu Matilainen -
Petr Lautrbach -
Reindl Harald -
Toshio Kuratomi