Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 231744 - error: Couldn't exec perl-devel-prov: No such file or directory
error: Couldn't exec perl-devel-prov: No such file or directory
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2007-03-10 20:26 EST by Robert Scheck
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-12 14:33:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2007-03-10 20:26:29 EST
Description of problem:
When rebuilding perl-5.8.8-15, I'm ending up with:

--- snipp ---
Obsoletes: perl-Filter-Simple perl-Time-HiRes
Processing files: perl-devel-5.8.8-15
error: Couldn't exec /usr/src/rpm/BUILD/perl-devel-5.8.8/perl-devel-prov: No 
such file or directory
getOutputFrom(): Broken pipe
--- snapp ---

But when rebuilding perl-5.8.8-13, stuff works as expected. When comparing -13 
and -15, I can't see the reason for the problem. Any ideas?

Version-Release number of selected component (if applicable):

How reproducible:
Everytime, see above.

Actual results:
No working rebuild.

Expected results:
Working rebuild.
Comment 1 Robin Norwood 2007-03-12 11:32:31 EDT
strange - obviously seems related to the filtering of provides we do in the
%prep section, starting around line 283:

# Oh, the irony. Perl generates some non-versioned provides we don't need.
# Each of these has a versioned provide, which we keep.
cat << \EOF > %{name}-prov
%{__perl_provides} $* |\
    sed -e '/^perl(Carp)$/d' |\
    sed -e '/^perl(DynaLoader)$/d' |\
    sed -e '/^perl(Locale::Maketext)$/d' |\
    sed -e '/^perl(Math::BigInt)$/d' |\
    sed -e '/^perl(Net::Config)$/d' |\
    sed -e '/^perl(Tie::Hash)$/d' |\
    sed -e '/^perl(bigint)$/d' |\
    sed -e '/^perl(bigrat)$/d' |\
    sed -e '/^perl(bytes)$/d' |\
    sed -e '/^perl(utf8)$/d'
%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
chmod +x %{__perl_provides}


This is the standard method of filtering provides:


And I can't see why %{name} would be perl-devel instead of 'perl' - I thought
%{name} was always the name of the source rpm.

I also can't reproduce this here - can you send me your commandline and maybe
~/.rpmmacros ?

Comment 2 Robin Norwood 2007-03-12 11:44:42 EDT
Also, could you let me know what version of RPM you're using to build?

Specifically, if you're using jbj's builds, this could be an implementation

Comment 3 Tom "spot" Callaway 2007-03-12 12:06:47 EDT
%{name} should never be getting reassigned to perl-devel... very very strange.
Comment 4 Robin Norwood 2007-03-12 12:53:08 EDT
background: Did some talking with nastrat and f13 on #fedora-devel - they agree
that %{name} shouldn't be 'fedora-devel'.  I'll try to reproduce this once I get
more information from Robert.  I'm thinking this is not a perl specfile bug, though.
Comment 5 Robert Scheck 2007-03-12 13:36:32 EDT
I read your talk at #fedora-devel. Well, when rebuilding of -13 works with the 
same RPM version used for -15 (where it fails), does it matter which RPM it is?
Comment 6 Tom "spot" Callaway 2007-03-12 13:38:47 EDT
Yes, it does. No one can reproduce this with the RPM in Fedora. If you're using
some other version of RPM, it is likely a bug in that other version of RPM, and
not this perl spec file.
Comment 7 Robin Norwood 2007-03-12 13:58:50 EDT
Also, the spec file changed dramatically between -13 and -15.
Comment 8 Robert Scheck 2007-03-12 14:23:02 EDT
Sorry, but your comment made me laughing. Did you ever do a diff between -13 
and -15? You're adding some comments, changing description and moving a couple 
of files from perl core to -devel (which already exists in -13). Whatever means 
dramatically ;-)


Of course it could be a bug within upstream RPM, that's why I'm adding the long-
time father. Jeff, I should be able to provide you a reproducer (if needed) 
when the rebuild of perl package I started now, fails once more. Walking home 
for now first...
Comment 9 Robin Norwood 2007-03-12 14:31:31 EDT
Sorry, I had -13 confused with -12, which was the pre-rewrite version.  

Regardless, I can't reproduce this here, and will need more information as
described above or a solid reproduction case.

Comment 10 Tom "spot" Callaway 2007-03-12 14:33:12 EDT
Somehow, your custom version of RPM is getting %{name} set to perl-devel. As
this should never happen (and doesn't happen in the Fedora RPM), this is
NOTABUG. This is evident from the path in your first post:

error: Couldn't exec /usr/src/rpm/BUILD/perl-devel-5.8.8/perl-devel-prov: No 
such file or directory

The fact that %{name} is being mis-set is obviously a bug in your RPM
implementation, not Fedora's.
Comment 11 Jeff Johnson 2007-03-12 14:45:02 EDT
rpm-4.4.8 sets per-subpackage names. Not a bug, a PLD requested feature. DIscussed and everything.

Meanwhile, changing s/%{name}/perl/ willl work.
Comment 12 Robin Norwood 2007-03-12 14:56:10 EDT
Thanks for the update, Jeff.
Comment 13 Jeff Johnson 2007-03-13 07:27:46 EDT
Using %{name} in the following is rather silly, just rename to perl-prov, there is no
benefit to using %{name} that I can see:

# Oh, the irony. Perl generates some non-versioned provides we don't need.
# Each of these has a versioned provide, which we keep.
cat << \EOF > %{name}-prov
%{__perl_provides} $* |\
    sed -e '/^perl(Carp)$/d' |\
    sed -e '/^perl(DynaLoader)$/d' |\
    sed -e '/^perl(Locale::Maketext)$/d' |\
    sed -e '/^perl(Math::BigInt)$/d' |\
    sed -e '/^perl(Net::Config)$/d' |\
    sed -e '/^perl(Tie::Hash)$/d' |\
    sed -e '/^perl(bigint)$/d' |\
    sed -e '/^perl(bigrat)$/d' |\
    sed -e '/^perl(bytes)$/d' |\
    sed -e '/^perl(utf8)$/d'
%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
Comment 14 Jeff Johnson 2007-03-13 07:29:13 EDT
You can also just expand immediately using %{expand:...} rather than lazily (which is where the perl-devel 
is being substituted.

Comment 15 Jeff Johnson 2007-03-13 07:31:45 EDT
FWIW, %{name}-%{version} rather than %{buildsubdir} just happens to work, can/will break when %setup -n 
yadda-yadda is used.
Comment 16 Robin Norwood 2007-03-13 11:24:08 EDT
comment #13 - the reason that %{name} is used is because we cut-n-paste the
snipped from this page:


all over our perl rpms.  Not really a *good* reason...but a reason.

comment #15: Seems like a good idea, but doesn't seem to work for me here. 
Maybe a bug/difference in Fedora's rpm.

Comment 17 Jeff Johnson 2007-03-13 13:19:49 EDT
Fix the wiki. There's no reason why %name needs to be used for a script name that I can see.

Yes, %buildsubdir is tricky because it isn't defined until after %setup is actually run during %prep. This 
means that a macro expansion during before %setup is run won't see the value defined. Adding a 2nd
% escape character might delay the expansion until after %setup is run, but that's pretty obscure 

There's some change since 4.4.2 to buildsubdir, I'm too lazy to check. Assuming CWD is
correct is easiest fixing.

Meanwhile, there are other means to carry a per-package script, including
    1) SourceN: some script, and then use %SOURCEn tio define %__perl_{provides,requires}
    2) Use mktemp to generate a unique name in /tmp with a here document.
    3) Don't use the full path, the CWD (assuming no other cd's) is always the top of
    the build directory.

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