[Bug 757156] Review Request: perl-Env-C - Get/Set/Unset Environment Variables on the C level

[bugzilla at redhat.com]

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 #10 from Paul Howarth <paul at city-fan.org> 2011-12-08 06:56:24 EST ---
(In reply to comment #8)
> OK, here is the quoted discussion with the upstream package author. Lines
> prefixed with ">" are mine, and lines prefixed with ":" are written by the
> package author:
> 
> : > : Personally, I don't really care which exact of the free-as-a-beer
> : > : license is used, GPL, Artistic XYZ, or whatever you'd like it to be.
> : >
> : >       OK. So "the same terms as Perl itself" would be OK with you?
> : [...]
> : >       So if you say "the same terms as Perl itself" or "Artistic 2.0"
> : > or "Artistic clarified" is OK with you, I would be able to package
> : > Env::C for Fedora.
> : 
> : Yes, either of the above works. I doubt I'll release a new version of
> : the module just to tweak this, unless it's really important. Perhaps
> : you can just quote this communication as a proof.
> 
> Is it sufficient to have it this way and keep License: Artistic 2.0
> in the spec file?

Yes, but include the email from the author saying this is OK as one of the %doc
files in the package. That's what happened a while back for perl-NetAddr-IP,
which had the same issue.

http://pkgs.fedoraproject.org/gitweb/?p=perl-NetAddr-IP.git;a=blob;f=License_of_perl-NetAddr-IP.txt;h=661544743aa94efa0c8e55501ffb6a755c5dd921;hb=b803a15fae9080ce0fd35bbdaab73fd168d0d275

(In reply to comment #9)
> Re: comment #7
> > 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?
> 
> I want to contribute packages which I need myself, but recently everything I
> have needed was already packaged except some Perl modules. So for now, I will
> stick with Perl modules. (context: I have been building RPM packages for at
> least 12 years now, does anybody here remember Red Hat Contrib|Net, the early
> community packaging effort for Red Hat Linux?).

The issue here is that perl module packages tend to be very formulaic and
generally don't need much tweaking from what you get out of cpanspec. As a
result, package submissions of perl modules don't provide much insight into
your understanding of packaging in general or the Fedora guidelines in
particular. The usual approach to demonstrating this understanding is to do
unofficial reviews of other packages like Willington did for this one (though
preferably not just perl modules).

> > Are there any more "leaf" packages, that don't have any non-Fedora
> > dependencies?
> 
> E.g. perl-TeX-Encode, perl-Scalar-String, perl-IO-Socket-Multicast,
> perl-Data-Integer, perl-Data-Float, or perl-DBD-ODBC.

If there's any of those with anything "unusual" about them, submit that, else
pick one at random for now.

> > > 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.
> 
> Well, perhaps the Packaging:Perl wiki page should be modified to not have this
> requirements then? (I cannot check the exact wording as Fedora wiki currently
> says 503 Service Unavailable for me).

Maybe the wording could be clearer. The guideline is talking about which
directories must be owned by the package, by way of some sample %files entries.
The important bit is the directory ownership rather than the implementation
though.

-- 
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.