perl and multilib considerations?

[Radu Greab]

At Mon, 19 Jan 2004 00:57:19 -1000,
Warren Togami wrote:
> 
> 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}')
cye
> >
> >
> > 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
> 
> 
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>