Re: perl and multilib considerations?

[Warren Togami <warren togami com>]

Florian La Roche wrote:
> On Sun, Jan 18, 2004 at 11:12:03PM -1000, Warren Togami wrote:
>
> > 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.
>
> You don't have to change it if perl is updated, this is giving
> only a minimal perl version number.

/usr/lib/perl5/5.8.0/
RHEL3
/usr/lib/perl5/5.8.1/
FC1
/usr/lib/perl5/5.8.2/
Rawhide now
/usr/lib/perl5/5.8.3/
Rawhide soon according to cturner

Stuff that depends on perl needs to require the exact %{version} of the 
perl that it was built upon, because the directory names contain that 
%{version}.  For this reason the above Requires is not entirely correct. 
 Everything that depends on perl (with the exception of stuff that only 
calls /usr/bin/perl for interpreting) must also be rebuilt when perl 
%{version} is upgraded for this reason.

Although please correct me if I am wrong.  It would be nice if this 
"problem" would go away one day, but it is a really non-trivial problem.

> > Requires: %(perl -le 'use Config; print $Config{archlibexp}')
> > Does this spec line fail in any cases you can think of?
>
>
> Shudder. Is xchat that dependent on the current perl or is
> that only a savety measure to guard against future perl
> changes?
>
> As Jeff Johnson is pointing out on a regular basis: automation
> is much better than cleanup of things that get faster out of
> date than you are able to get them right.

I would agree that better automation and checking tools would HELP in 
analyzing and understanding behavior, but it is an exceedingly difficult 
problem to program in all possible cases.  However difficult, I would 
agree that it is worth doing one of these days if we have more manpower 
and clear specicications about what such tools should do written.

I currently believe that such tools would be effective only in 
understanding behavior necessary to specify explicit requirements and 
procedures in spec files, and also request that upstream fix certain 
aspects of their Makefiles to make things smoother in the future.  I am 
not convinced that those tools can fully automate it to a point where 
humans no longer need to analyze each case and write explicit 
requirements into each package recipe.

Warren