On Sun, Jan 4, 2015 at 3:01 AM, Ralf Corsepius <rc040...@freenet.de> wrote:
> On 01/04/2015 07:41 AM, Anshu Prateek wrote:
>>
>> hi,
>>
>> I am working on packaging an upstream (aerospike) which presently puts
>> some of its file in /opt/aerospike.
>>
>> The two main folders in use (by upstream) are
>>
>> /opt/aerospike/sys/udf/lua - This has the user defined lua functions
>> shipped with the package.
>> /opt/aerospike/usr/udf/ - This will have the user's custom UDFs.
>>
>> What will be the right place in FHS to put the above two directories
>> when packaging for Fedora? Should these go into /usr/share/aerospike or
>> some place in /var?
I think the useful place to put it is to get aerospike to publish
their SRPM, especially their spec files. I'm looking at the RHEL rpm
for their c-client tool, and it shoves some things in /op, and some in
/usr/lib for the 64-bit version, which rather violates the /usr/lib64
location for the libraries.
> Impossible to tell without having seen the sources and without knowing the
> contents. /usr/share/<package>, /usr/lib/<package>,
> /usr/{lib,lib64}/<package> would seem likely candidates.
I looked at this once before and it started making me twitch. Anyone
who publishes a system specific tarball, and puts the sources and
several RPM's *inside* the same tarbal but can't be bothered to
include a .spec or SRPM is just being goofy.
> Packages installing to /opt are not allowed in Fedora. In most cases, such
> packages are simply incorrectly configured.
>
> Ralf
The "FileSystem Hierarchy", "File Hierarchy System", and its other
three-letter descriptions had their last official release in 2004.
It's in the process of an update to version 3.0. The beta version is
at http://www.linuxbase.org/betaspecs/fhs/fhs.html. It's pretty clear
that "/opt is reserved for the installation of add-on application
software packages.".
It's common for third party packages that require their own
non-system-standard libraries and binaries for Perl, Python, MySQL,
HTTPD, and god knows Python and Ruby use /opt to have a modular
installation that does not step on your system libraries. God knows
that commercial software vendors use it, and even some open source
vendors like Opscode use it for "chef" software.
Also note that Fedora does not follow the FHS word-for-word. The
merging of /bin with /usr/bin, /sbin with /usr/sbin, etc. is a clear
violation of even the latest proposed FHS. And the use of
"/var/run/meda" for user-owned mounted media, built into "systemd", is
a pretty clear violation of the specification for all three "/var",
"/run", and "/media. Getting violated 3 ways at once, well, I hope it
was thrilling for *everyone*.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
