Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=757156
--- Comment #7 from Paul Howarth paul@city-fan.org 2011-12-06 13:58:20 EST --- (In reply to comment #6)
Re: comment #5
I have asked upstream to clarify the licensing.
Good.
No, I have not submitted any other packages. Should I submit them? I wanted to go through the whole process of making a Fedora package with the single package first.
The whole process can't continue much further with this one until the license is clarified unfortunately, which is why it would be a good idea to submit a few others too.
Regarding your plans for participation in Fedora, do you see yourself sticking to perl modules or might you have other things to bring in in the future?
If anybody is interested in (pre-)review, I have uploaded them to http://www.fi.muni.cz/~kas/tmp/fedora-packages/. Some of them cannot be built in mock as-is, because they depend on other packages from this set, so they have probably to be reviewed in a single request.
Are there any more "leaf" packages, that don't have any non-Fedora dependencies?
Also, they all currently have the problem mentioned in comment #1 (directory ownership of %{perl_vendorarch}... as created by cpanspec).
This is more a matter of taste. If I was packaging this module, I'd use:
%files %defattr(-,root,root,-) %doc Changes README %{perl_vendorarch}/auto/Env/ %{perl_vendorarch}/Env/ %{_mandir}/man3/Env::C.3pm*
I prefer to keep wildcards to a minimum so that if future versions start shipping different files, I notice it and can investigate to see if it's a problem or not. What's important is that your package "owns" the necessary directories and files. All versions of this package that you have submitted thus far satisfy that requirement.