Difference between revisions of "Documentation/Labs/FHSCompliantDirectoryStructure"

From Slicer Wiki
Jump to: navigation, search
m
 
Line 1: Line 1:
The current install tree structure as documented on [[Documentation/Nightly/Developers]] is not fully compliant with the [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Filesystem Hierarchy Standard]. This page aims at documentation how the structure could be updated.
+
The current install tree structure as documented on [[Documentation/Nightly/Developers]] is not fully compliant with the [https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Filesystem Hierarchy Standard]. This page aims at documenting and discussing how the structure could be updated.
  
 
== Rationale ==
 
== Rationale ==

Latest revision as of 22:41, 10 April 2014

Home < Documentation < Labs < FHSCompliantDirectoryStructure

The current install tree structure as documented on Documentation/Nightly/Developers is not fully compliant with the Filesystem Hierarchy Standard. This page aims at documenting and discussing how the structure could be updated.

Rationale

For reasons that hopefully do not require enumeration, it is desirable for Slicer to install in a reasonable manner to a system standard prefix, e.g. /usr/local or even /usr. Ultimately, it would be very cool if distributions were able to package slicer, for which reasonable FHS compliance is a requirement.

Proposal

(Originally by Matthew Woehlke - April 10, 2014)

  • move /Slicer[1] to /bin/
  • move /bin/Python[2] to one[3] of:
    • /lib/python-${PyVer}/site-packages
    • /lib/python-${PyVer}/site-packages/slicer${VerMajor}
    • /share/Slicer-${Ver}/
      • ...and move /bin/Python/SlicerWizard to /lib/python-${PyVer}/site-packages
  • move /lib/Python/*[4] to /
  • move /lib/TclTk/*[4] to /
  • move /lib/QtPlugins[5] to /lib/Slicer-${Ver}/
  • move /lib/Slicer*/<third party libs>[4] to /lib/
  • move /bin/Slicer{LauncherSettings.ini,SplashScreen.png}[6] to /share/Slicer-${Ver}/

(As a side note, honoring LIB_SUFFIX also would be nice. This is common idiom in e.g. Fedora packaging to install libraries to lib64 rather than lib, when building for architectures where that is appropriate.)

Footnotes

  1. The FHS (e.g. 3.1) strongly discourages adding entries to / or /usr. Anyway, this clearly should be in /bin so that it is in a reasonable PATH. On UNIX systems where PREFIX=/opt/<product> (or perhaps as a CMake option), it might be okay to install a symlink in ${PREFIX}. On Windows, a shortcut could be used similarly.
  2. 3.4.2 forbids subdirectories in /bin. While not stated explicitly for /usr/bin, many systems now symlink /bin to /usr/bin, implicitly forwarding the prohibition. Additionally, the files contained herein are not executables but are library code that clearly belong under /lib or /share.
  3. Which option is selected is left to discussion. One of the /lib choices is probably more conformant, but would make these modules accessible from a standard Python shell, which may not be desirable (except for SlicerWizard).
  4. For a standard installation, all products should be installed to ${PREFIX}; <product>_PREFIX=${Slicer_PREFIX}/lib/<product> is non-standard.
  5. Convention for third party Qt plugins (e.g. see KDE) is a subdirectory (e.g. plugins) of /lib/<product>.
  6. These non-executable files do not belong in /bin. While the .ini could possible be placed in /etc, this requires special handling in the case that PREFIX=/usr; /share/Slicer-<Version> also seems like a reasonable location and does not have this issue.

Section references in the above are given for the PDF version of FHS 2.3. (The HTML version unfortunately does not number sections.)