perl and multilib considerations?
Warren Togami
wtogami at redhat.com
Mon Jan 19 08:50:07 UTC 2004
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.
More information about the fedora-devel-list
mailing list