perl and multilib considerations?
Warren Togami
warren at togami.com
Mon Jan 19 10:57:19 UTC 2004
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
More information about the devel
mailing list