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
#!/bin/sh
%{__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'
EOF
%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
chmod +x %{__perl_provides}


---------------

This is the standard method of filtering provides:

http://fedoraproject.org/wiki/Packaging/Perl

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 ?

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
difference.

Thanks.

%{name} should never be getting reassigned to perl-devel... very very strange.

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.

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?

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.

Also, the spec file changed dramatically between -13 and -15.

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 ;-)

http://cvs.fedora.redhat.com/viewcvs/devel/perl/
perl.spec?r1=text&tr1=1.107&r2=text&tr2=1.109&diff_format=h

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...

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.

Thanks.

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.

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.

Thanks for the update, Jeff.

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
#!/bin/sh
%{__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'
EOF
%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov

You can also just expand immediately using %{expand:...} rather than lazily (which is where the perl-devel 
is being substituted.

FWIW, %{name}-%{version} rather than %{buildsubdir} just happens to work, can/will break when %setup -n 
yadda-yadda is used.

comment #13 - the reason that %{name} is used is because we cut-n-paste the
snipped from this page:

http://fedoraproject.org/wiki/Packaging/Perl

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.

Thanks.

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 
behavior.

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.