Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 231744 - error: Couldn't exec perl-devel-prov: No such file or directory
Summary: error: Couldn't exec perl-devel-prov: No such file or directory
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-11 01:26 UTC by Robert Scheck
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-03-12 18:33:12 UTC

Attachments (Terms of Use)

Description Robert Scheck 2007-03-11 01:26:29 UTC
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 15:32:31 UTC
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 15:44:42 UTC
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 16:06:47 UTC
%{name} should never be getting reassigned to perl-devel... very very strange.

Comment 4 Robin Norwood 2007-03-12 16:53:08 UTC
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 17:36:32 UTC
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 17:38:47 UTC
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 17:58:50 UTC
Also, the spec file changed dramatically between -13 and -15.

Comment 8 Robert Scheck 2007-03-12 18:23:02 UTC
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 18:31:31 UTC
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 18:33:12 UTC
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 18:45:02 UTC
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 18:56:10 UTC
Thanks for the update, Jeff.

Comment 13 Jeff Johnson 2007-03-13 11:27:46 UTC
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 11:29:13 UTC
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 11:31:45 UTC
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 15:24:08 UTC
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 17:19:49 UTC
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.