Bug 856584 - UsrMove problems
UsrMove problems
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-12 07:09 EDT by Harald Reindl
Modified: 2012-10-30 10:42 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-30 09:09:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Harald Reindl 2012-09-12 07:09:25 EDT
WHAT is responsible for "/bin/perl" as dependency

this results in the following error triggered by a
perl-update providing the CORRECT path /usr/bin/perl

 Error: Package: httpd-devel-2.2.23-5.fc17.20120823.rh.x86_64 (@rhsoft-fedora)
           Requires: /bin/perl
           Removing: 4:perl-5.14.2-213.fc17.x86_64 (@updates-testing)
               Not found
           Updated By: 4:perl-5.14.2-214.fc17.x86_64 (updates-testing)
               Not found

____________________

Processing files: httpd-devel-2.2.23-5.fc17.20120912.rh.x86_64
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/perl /bin/sh perl >= 0:5.004 perl(strict)
____________________

changing this file does not fix it
but however - REMOVE the /bin and /sbin in front of the real locatiobns

[root@testserver:/usr/lib/rpm]$ cat /usr/lib/rpm/perldeps.pl | grep "/bin:/usr/bin"
    $ENV{"PATH"} = "/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/ucb";
Comment 1 Harald Reindl 2012-09-12 10:33:14 EDT
seel also
https://bugzilla.redhat.com/show_bug.cgi?id=856590

i have no idea what is happening here expect UsrMove is still a problem
Comment 2 Harald Reindl 2012-09-12 10:54:43 EDT
/rpm-4.9.1.3/lib/rpmscript.c Line 85
static const char * const SCRIPT_PATH = "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin";


/rpm-4.9.1.3/macros.in Line 292
# The PATH put into the environment before running %pre/%post et al.
#
%_install_script_path	/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin


maybe THIS is the reason why "rpmbuild" finds "/bin/perl", put it in deps of a package and while update perl which provides correct /usr/bin/perl it comes to dependecy-troubles

WHY are maintainers of core-packages are not cleaning up there sources in case auf a change like UsrMove to prevent such things from happening?
Comment 3 Panu Matilainen 2012-09-12 14:21:41 EDT
(In reply to comment #2) 
> WHY are maintainers of core-packages are not cleaning up there sources in
> case auf a change like UsrMove to prevent such things from happening?

Maybe because nobody has filed a bug about this before, and I haven't happened to encounter it?

Oh and BTW, do something about your capslock key. I didn't invent this particular misery, on the contrary I was rather outspoken against the whole usrmove thing, especially on such a rushed schedule. Yelling at me is not going to make me care more.
Comment 4 Panu Matilainen 2012-09-12 16:41:01 EDT
'rpm -qp --filerequire <pkg>' is handy for figuring where a given dependency originates from. In this case, the probable source of that /bin/perl vs /usr/bin/perl is this:

[pmatilai@turre httpd-2.2.22]$ head -1 support/apxs.in
#!@perlbin@ -w

That gets determined somewhere in the httpd configure/make system, presumably based on $PATH. Neither rpm(-build) or redhat-rpm-config touches PATH (the paths you mention are install-, not build-time execution paths as the comment says), so PATH is whatever that happens to be in effect on the account you're building on.
Rpm could of course enforce a "sane Fedora $PATH" in there, but if it did somebody would file a bug about rpm messing with their $PATH breaking their builds...
Comment 5 Harald Reindl 2012-09-13 04:42:55 EDT
> Rpm could of course enforce a "sane Fedora $PATH" in there, 
> but if it did somebody would file a bug about rpm messing 
> with their $PATH breaking their builds...

for a distribution-wide change this should be done instead need to deal in random upstream sources 

currently a "Requires: /usr/bin/perl" seems to be a wrokaround in the SPEC to prevent rpmbuild from the auto-generated Require with the wrong path
Comment 6 Panu Matilainen 2012-10-30 09:09:30 EDT
Having mulled over this a bit... I dont see anything to fix here:

The issue here is not a generic one but just a random upstream make system relying on $PATH (which is not set by rpm) to create a shebang for a script, which rpm picks up. Having to possibly adjust for something like that is not much different from fixing references to eg #!/usr/local/bin/perl - not an uncommon thing in upstream sources.

Rpm has never enforced any particular PATH during build, and making it do so would only create different kind of problems.
Comment 7 Harald Reindl 2012-10-30 09:27:01 EDT
well - i had to build a meta-package with "Provides: /bin/perl" to really solve the repeated problem if any package is updated at the same time as perl itself which is only providing /usr/bin/perl deps are broken

there should be NO single packe come out from rpmbuild/koji which Requires /bin/aynthing because these troubles will happen all the time if specific packages are updated at the same time
Comment 8 Panu Matilainen 2012-10-30 10:01:22 EDT
The thing is, rpm does not *invent* those /bin/foo paths, it only "reports" what it finds: if a script starts with "#!/bin/foo" then /bin/foo is what you get as a dependency. If /bin/perl is turning up a lot, then somebody (perl SIG perhaps) should look into where they are coming from and address that.
Comment 9 Harald Reindl 2012-10-30 10:42:01 EDT
well, here the bugreport against perl
https://bugzilla.redhat.com/show_bug.cgi?id=871503

that is why i still mean that usrMove was a very bad idea with zero benefit

Note You need to log in before you can comment on or make changes to this bug.