<div class="gmail_quote">On Wed, May 18, 2011 at 2:00 PM, Fred Moyer <span dir="ltr"><<a href="mailto:fred@redhotpenguin.com">fred@redhotpenguin.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Wed, May 18, 2011 at 10:37 AM, Chris Weyl <<a href="mailto:cweyl@alumni.drew.edu">cweyl@alumni.drew.edu</a>> wrote:</div></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

> I generally set %_prefix to /usr/perl-%{version} instead of /opt/... as I'm<br><div class="im">
> given to understand that /opt is reserved for packages completely<br>
> independent from the system itself (e.g. self-satisfying to just about all<br>
> dependencies) and the non-system Perl packages I build still leverage parts<br>
> of the installed system (e.g. shared libraries) and express RPM dependency<br>
> information.  I suspect this might get a touch religious, however. :)<br>
<br>
</div>What do you mean by 'completely independent'?  Perhaps /usr/local/ is<br>
a good approach here.<br></blockquote><div><br>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.<br>

<br>/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 :))<br>

</div><div><br>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.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> I'm going on the assumption here that you don't want to replace the system<br>
> Perl package.  If this is the case, then you're going to want to steer clear<br>
> of the existing RPM/Perl metadata system (autogeneration of deps of the form<br>
> perl(Foo)), or you'll run into no end of trouble.  If you're building RPMs<br>
> to deliver CPAN package as well, you're going to need a way to declare<br>
> dependencies to RPM that satisfies their needs and doesn't conflict with the<br>
> system Perl dependency system.<br>
<br>
</div>That's right, I don't want to replace it.<br>
<br>
Ah, this brings back memories of building RPMs for the separate perl<br>
binary rpm.  It is looking like I will need to prefix the binary and<br>
associated module rpms with a namespace to differentiate them from the<br>
system Perl module rpms.<br></blockquote><div><br>Yeah -- it gets exciting otherwise :)<br></div></div><br>                              -Chris<br><br>[1] <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES">http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES</a><br>

[2] <a href="http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY">http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY</a><br><br clear="all"><br>-- <br>Chris Weyl<br>Ex astris scientia<br>