* 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@xxxxxxxxxx
