perl and multilib considerations?

[Chip Turner]

Warren Togami <wtogami at redhat.com> writes:

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

Basically a package built for 5.8.2 needs 5.8.2 or higher; however,
perl 5.8.2 will run a package built for 5.8.0.  IOW, it's backwards
compatible; perl updates include the old dirs in @INC and such so they
see the old packages.

> 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'd rather use a virtual provide in the perl package that modules
could use than using path info like that, though the directories would
work.  Something like:

perl.spec:
Provides: perl(:5.8)

spamassassin.spec:
Requires: perl(:5.8)
BuildRequires: perl(:5.8)

(:5.8 made up completely, I'm sure there are better placeholder
strings; generally, perl(:WITH[OUT]_FOO) has been used in the past
when we were transitioning compiler params that broke binary
compatibility inside the same major perl version (ie, 5.6).  The
perl() RPM require/provide namespace is used to set up module
requirements, and the leading colon is the hueristic I've been using
to indicate something slightly outside of the regular perl module
requires we use the namespace for).

It would be necessary to manually update those tags when 5.10 comes
out, but generally speaking, transitions across major perl revisions
requires other changes to specfiles anyway.

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

xchat is a bit different in that it embeds perl; most perl modules
don't.

Shipping a 32bit and 64bit perl on the same system won't work since
/usr/bin/perl is an executable and not set up to allow peaceful
coexistence; we don't do this in any RHL or RHEL release to date and
there aren't really any plans to.  To date, no external 32bit progs
have wanted access to a 32bit perl in a 64bit environment that I am
aware of.

Chip

-- 
Chip Turner                   cturner at redhat.com
                              Red Hat, Inc.