hi,
I am trying to package Aerospike (http://aerospike.com) which presently puts its two rpm (server and tools) 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? Or some place inside /opt/fedora/aerospike?
There are two other folders - /opt/aerospike/example which could go into /usr/share/docs/aerospike and /opt/aerospike/lib/python which will need clarification as well. In case it goes to /opt/fedora , would it be the right folder when being packaged for epel as well?
I am inclined to close this ticket as invalid.
C.f. the mail I just posted to @devel.
Well, our current guidelines do indicate that if a packager feels that use of /opt is justified, they should file a ticket. I haven't seen any justification for putting anything under /opt here, and am generally inclined to vote against any use of /opt without extensive justification (and probably still even then).
Just put the files where appropriate. Binaries in /usr/bin, library files in /usr/lib(64), non-arch-specific data under /usr/share, files created by end-user action under /var, documentation under /usr/doc, python libraries under the proper python directory hierarchy if appropriate, etc. This is no different from any other package in the system.
Thanks all, the mail thread (and this) answered my queries.
Replying to [comment:2 tibbs]:
Well, our current guidelines do indicate that if a packager feels that use of /opt is justified, they should file a ticket.
IIRC, this rule only exists to allow /opt/redhat rsp. /opt/fedora to allow RedHat/CentOS/Fedora provided "add-on" packages. Something which at least I believe does not make any sense for Fedora and only very limited sense on RHEL/CentOS.
I don't disagree; I'm just pointing out that there's a reason a packager would file such a ticket, in response to your comment that you were inclined to mark this ticket invalid. Perhaps the language in the guidelines which suggests doing such should be modified to indicate the significant amount of justification which would be required.
Login to comment on this ticket.