FC4 perl module upgrades/cleanups

[Warren Togami]

Robert Scheck wrote:
> 
>>* Identify all modules that have a newer version available in CPAN. 
>>Would be nice if we had a script to compare a devel CVS checkout to CPAN 
>>and output a list with URLs or something.
>>
>>Contributors like Ville, Robert and Jose have been very helpful in 
>>submitting good spec rewrites for perl packages in the past.  So I hope 
>>the community can help with cleaned up spec unidiffs (along with version 
>>upgrades) to be submitted to Bugzilla, one report per package.  Perhaps 
>>discuss here who will do which package.  I'll do some myself.
> 
> 
> As of today, many perl packages have duplicate reports named differently.
> Maybe we can open something like a tracker bug for the corresponding
> perl packages and add the different/similar wishes, duplicates etc to them
> for having a better overview what's to do for which package? 

I don't know if a tracker would be the best idea.  The key goal I think 
we need here is to form a Fedora perl team, who receives notification of 
all perl bugs and makes decisions about perl* package changes.  If a 
tracker would be the best way to do this, then fine.

Another option would be auto-CC in Bugzilla, where I can specify people 
who should automatically be added CC to certain components.  I can put 
Fedora perl team members in here.  I would prefer this.  Thoughts?

> 
> * We should run "make test" at every package (if available of course) and
>   non-conditional - if it fails, something is wrong.

This would be acceptable only if those tests NEVER TOUCH THE NETWORK. 
It is completely unnacceptable for rpmbuild to use the network.

There are other possible dangers in enabling "make test", some of which 
were discusssed on this list in the "Regression testing" thread.  For 
now DO NOT enable this until we discuss this a lot more.

> 
> * Most perl packages are named perl-Foo-Bar and the CPAN "realname" is
>   Foo-Bar, we shouldn't define a separate variable for this as some
>   packages currently do, normally, the CPAN name is only needed at setup -q
>   -n Foo-Bar-%{version}. Macrofying is generally okay, but we're not
>   generating tons of spec files like DAG or so.

I really don't care about this.  My mind leans slightly toward the "keep 
the spec as simple as possible" and wants to avoid unnecessary macros. 
This however would make sense if the macroified name is used many times 
in the spec, but I don't think this is the case here.

> 
> * Valid Group and License values! See /usr/share/doc/rpm-4.4.1/GROUPS and
>   COPYING/README/... file of the corresponding package. Groups like
>   Applications/CAN, Applications/Perl, Perl/CAN etc are not valid.

Thanks for reminding us.  Ugh...

We also need to seriously consider redoing those GROUPS one of these 
days, but this is far beyond the scope of this perl cleanup.

> 
> * Update the %doc sections, some packages don't have this section, but the
>   CPAN packages normally contain some useful files like README, ChangeLog.

If they are tiny, then fine.  Otherwise I'm wary because we really have 
   to avoid further bloating the distribution.  I look forward to the 
day of 2 DVD's for FC installation...

Warren Togami
wtogami at redhat.com