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(a)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.
--
Configure bugmail:
https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.