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

[Chris Weyl]

On Wed, May 18, 2011 at 2:00 PM, Fred Moyer <fred at redhotpenguin.com> wrote:

> On Wed, May 18, 2011 at 10:37 AM, Chris Weyl <cweyl at alumni.drew.edu>
> wrote:
>
> 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. :)
>
> What do you mean by 'completely independent'?  Perhaps /usr/local/ is
> a good approach here.
>

This is actually something I've avoided by not ever installing anything into
/opt -- Fedora guidelines prohibit its use in any rpms.  The FHS addresses
it[1], but I've only ever seen things such as Java or various IBM Tivoli
products install in there.  My understanding of "independent" means that
they're either statically linked or only link to the standard libraries that
are (hand-waving here) guaranteed to be on every system.  The FHS says one
thing, but vendors do what they want here, essentially.

/usr/local is similarly restricted -- it's reserved for site or system
adminstrators to install into, not anything delivered by a Fedora/RHEL
rpm.[2]  If you were building Perl locally, this is where you'd want to put
it.  (Or at least where the FHS wants you to want to put it :))

Strictly speaking, my use of /usr directly (e.g. /usr/perl-x.y.z) is also
prohibited by the FHS... and the definitions for /opt seem more in line with
the usage we're talking about.  Hm, interesting.  I might need to rethink my
avoidance of /opt here.

> 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.
>
> That's right, I don't want to replace it.
>
> Ah, this brings back memories of building RPMs for the separate perl
> binary rpm.  It is looking like I will need to prefix the binary and
> associated module rpms with a namespace to differentiate them from the
> system Perl module rpms.
>

Yeah -- it gets exciting otherwise :)

                              -Chris

[1]
http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY


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