perl and multilib considerations?

[Warren Togami]

Requires: perl >= 2:5.8.2
spamassassin.spec contains this, which is problematic because it must 
change every time perl is upgraded.  The resulting SRPM needs to be 
modified if you rebuild it on older distributions too.  Not a totally 
serious problem, but annoying and consumes developer time on a 
reoccuring basis.

Requires: %(perl -le 'use Config; print $Config{archlibexp}')
Currently xchat.spec has this line in an attempt to avoid this problem.
x86 and x86_64 FC1 outputs this result from that command:
/usr/lib/perl5/5.8.1/i386-linux-thread-multi
/usr/lib64/perl5/5.8.1/x86_64-linux-thread-multi

I am thinking if this xchat.spec method of requiring the right version 
of perl that was in the buildsystem during rpmbuild time can safely be 
used universally.  Are there any cases where we will need to ship both 
32bit and 64bit perl in a distribution in order to satisfy the 
dependency of existing 32bit programs that may link to perllib?

There should be no problem with 32bit apps executing /usr/bin/perl 
directly since it should be functionally equivalent to what it expects. 
  Also I am thinking this is not a problem because the above perl 
command creates a directory dependency that should avoid Requiring the 
wrong perl arch, but I want to be sure I am not overlooking anything.

Requires: %(perl -le 'use Config; print $Config{archlibexp}')
Does this spec line fail in any cases you can think of?

Warren Togami
wtogami at redhat.com

p.s.
BuildRequires: %(perl -le 'use Config; print $Config{archlibexp}')
On a related note, one might be tempted to use this in spec files too, 
but think about it... perl would not be installed in order to output the 
directory name necessary to implicate itself for BuildRequires. =)

BuildRequires: perl
Instead this is proper in all cases.