perl and multilib considerations?

[Warren Togami]

Chip Turner wrote:
> 
>>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 suppose the next step is to design a standard and document it, then 
transition the entire package set to that standard.  Is there still 
enough time before FC2, or should we do this after FC2?

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

Thankfully so.  It just opens all kinds of ugly can of worms if you need 
to support this...

Warren