Hi Warren and folks,
On Thu, 31 Mar 2005, Warren Togami wrote:
> * Remove brp-compress calls from all packages, as it isn't doing
> anything useful. (Right?)
Right, at my Fedora Core Development system, /usr/lib/rpm/brp-compress vs.
/usr/lib/rpm/redhat/brp-compress only differs in calling gunzip/bunzip2
with or without the parameter "-f".
> * Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
> $version))
> Do we want this in all perl packages, both regular arch and noarch?
My personal opinion is all perl packages, because it shouldn't hurt or
break anything. Far from it! It can help to make sure, that the perl
dependencies are okay.
> * %define _use_internal_dependency_generator 0
> Many of the ancient specs have this. Might be nice to get rid of it,
> but it will require some careful verification comparing the before and
> after in order to be sure the rpm-auto-dep isn't demanding bad
> dependencies like Win32 crap. Is this worth doing? Need your opinions.
I'm not really familiar with _use_internal_dependency_generator in the
reference of perl, but if it isn't needed, we should avoid it.
> * 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?
> Thoughts?
* We should run "make test" at every package (if available of course) and
non-conditional - if it fails, something is wrong.
* Lots of the perl-* spec files have a part, where a ugly file list for the
%files section is generated. RPM has nice macros, which should replace
this file lists mostly (see: grep %perl_ /usr/lib/rpm/macros). And we
should have a look, that the packages also own their perl directories (if
possible); Ville, Jose and Warren already started in past solving this.
* 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.
* 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.
* Update the %doc sections, some packages don't have this section, but the
CPAN packages normally contain some useful files like README, ChangeLog.
Did I forget something?
Robert
