[sf-perl] Request for comments - Perl rpm builds

[Chris Weyl]

On Tue, May 17, 2011 at 10:46 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Mon, May 16, 2011 at 8:04 PM, Joseph Brenner <doom at kzsu.stanford.edu>
> wrote:
> > Sounds like a worthy experiment.  As far as names go, the way these
> > things are done in the ubuntu/debian world is a version number is
> > tacked on to the name.  So you might name the binary perl5.14 and call
> > the package perl5.14-5_14_0-0-i386.rpm.
>
> Thanks for the good feedback, I've renamed the rpms to contain the
> version, ala perl_5_14_0 which results in
> perl_5_14_0-5.14.0-1.i386.rpm
>
>
A couple thoughts from a cursory once-over:

You can use the canonical source package and location, and cause tell rpm
what directory to change into by:

%prep
%setup -q -n perl-%{version}

You're going to want to strip or rename the metadata given in the Provides
lines (e.g. the perl(Foo)), as that will conflict with the metadatasystem
provided by the system Perl package.

Automatic Perl metadata generation should be disabled, for the same reason
(conflicts with the system Perl package).  Generally speaking, this does the
trick without impacting other metadata generation:

%global __perl_requires %{nil}
%global __perl_provides %{nil}

Similarly, you're going to want to remove the "Obsoletes" lines.

%global vs %define: %define was the standard approach for years, but
eschewing %define for %global has become the norm in the Fedora/RHEL world
at this point.  (AFAICT the difference is in lazy evaluation -- %global is
evaluated and set as it's read, %defined as used.)

I generally set %_prefix to /usr/perl-%{version} instead of /opt/... as I'm
given to understand that /opt is reserved for packages completely
independent from the system itself (e.g. self-satisfying to just about all
dependencies) and the non-system Perl packages I build still leverage parts
of the installed system (e.g. shared libraries) and express RPM dependency
information.  I suspect this might get a touch religious, however. :)

I'm going on the assumption here that you don't want to replace the system
Perl package.  If this is the case, then you're going to want to steer clear
of the existing RPM/Perl metadata system (autogeneration of deps of the form
perl(Foo)), or you'll run into no end of trouble.  If you're building RPMs
to deliver CPAN package as well, you're going to need a way to declare
dependencies to RPM that satisfies their needs and doesn't conflict with the
system Perl dependency system.

Whew!  Now I'm feeling an itch to get back into reviewing Fedora packages
:-D

                           -Chris

-- 
Chris Weyl
Ex astris scientia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20110518/06ac4bf5/attachment.html>