Difference between revisions of "Documentation/Labs/FHSCompliantDirectoryStructure"

From Slicer Wiki
Jump to: navigation, search
(Created page with 'The current install tree structure as documented on Documentation/Nightly/Developers is not compliant with the [http://www.pathname.com/fhs/|File Hierarchy Standard]. This pa…')
 
m
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
−
The current install tree structure as documented on [[Documentation/Nightly/Developers]] is not compliant with the [http://www.pathname.com/fhs/|File 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 ==
  
−
From Matthew Woehlke  - April 10, 2014:
+
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. <tt>/usr/local</tt> or even <tt>/usr</tt>. Ultimately, it would be very cool if distributions were able to package slicer, for which reasonable FHS compliance is a requirement.
−
<pre>
 
−
I was thinking more about the bin/Python / bin/python-real issue, and got to thinking, it would be nice if Slicer did a better job following the FHS. Right now, anyone trying to install Slicer to a standard location (especially /usr, but even /usr/local) would make a mess of their file system.
 
  
−
To remedy this, I would suggest the following changes:
+
== Proposal ==
  
−
- move /Slicer [1] to /bin/
+
(Originally by Matthew Woehlke - April 10, 2014)
−
- move /bin/Python [2] to one of:
 
−
  - /lib/python-${PyVer}/site-packages
 
−
  - /lib/python-${PyVer}/site-packages/slicer${VerMajor}
 
−
  - /share/Slicer-${Ver}/
 
−
    - ...and move SlicerWizard to /lib/python-${PyVer}/site-packages
 
−
- move /lib/Python/* [3] to /
 
−
- move /lib/TclTk/* [3] to /
 
−
- move /lib/QtPlugins [4] to /lib/Slicer-${Ver}/
 
−
- move /lib/Slicer*/<third party libs> [3] to /lib/
 
−
- move /bin/Slicer{LauncherSettings.ini,SplashScreen.png} [5] to
 
−
  /share/Slicer-${Ver}/
 
  
−
Honoring LIB_SUFFIX would also be nice.
+
* move <tt>/Slicer</tt><sup>[[#fn1|[1]]]</sup> to <tt>/bin/</tt>
 +
* move <tt>/bin/Python</tt><sup>[[#fn2|[2]]]</sup> to one<sup>[[#fn3|[3]]]</sup> of:
 +
** <tt>/lib/python-${PyVer}/site-packages</tt>
 +
** <tt>/lib/python-${PyVer}/site-packages/slicer${VerMajor}</tt>
 +
** <tt>/share/Slicer-${Ver}/</tt>
 +
*** ...and move <tt>/bin/Python/SlicerWizard</tt> to <tt>/lib/python-${PyVer}/site-packages</tt>
 +
* move <tt>/lib/Python/*</tt><sup>[[#fn4|[4]]]</sup> to <tt>/</tt>
 +
* move <tt>/lib/TclTk/*</tt><sup>[[#fn4|[4]]]</sup> to <tt>/</tt>
 +
* move <tt>/lib/QtPlugins</tt><sup>[[#fn5|[5]]]</sup> to <tt>/lib/Slicer-${Ver}/</tt>
 +
* move <tt>/lib/Slicer*/&lt;third party libs&gt;</tt><sup>[[#fn4|[4]]]</sup> to <tt>/lib/</tt>
 +
* move <tt>/bin/Slicer{LauncherSettings.ini,SplashScreen.png}</tt><sup>[[#fn6|[6]]]</sup> to <tt>/share/Slicer-${Ver}/</tt>
  
−
Ideally, SlicerLauncherSettings.ini and SlicerSplashScreen.png (currently in /bin) should also be elsewhere (possibly /etc and /share, respectively, or both under /share), but that might be difficult due to how the launcher is set up. (OTOH the first item may require launcher changes anyway, in which case it would be better to go ahead and move them.)
+
(As a side note, honoring LIB_SUFFIX also would be nice. This is common idiom in e.g. [http://www.fedoraproject.org Fedora] packaging to install libraries to <tt>lib64</tt> rather than <tt>lib</tt>, when building for architectures where that is appropriate.)
  
−
What do you think?
+
=== Footnotes ===
  
 +
# <span id="fn1"></span> The FHS (e.g. 3.1) strongly discourages adding entries to <tt>/</tt> or <tt>/usr</tt>. Anyway, this clearly should be in <tt>/bin</tt> so that it is in a reasonable <tt>PATH</tt>. On UNIX systems where <tt>PREFIX=/opt/<i>&lt;product&gt;</i></tt> (or perhaps as a CMake option), it might be okay to install a symlink in <tt>${PREFIX}</tt>. On Windows, a shortcut could be used similarly.
 +
# <span id="fn2"></span> 3.4.2 forbids subdirectories in <tt>/bin</tt>. While not stated explicitly for <tt>/usr/bin</tt>, many systems now symlink <tt>/bin</tt> to <tt>/usr/bin</tt>, implicitly forwarding the prohibition. Additionally, the files contained herein are not executables but are library code that clearly belong under <tt>/lib</tt> or <tt>/share</tt>.
 +
# <span id="fn3"></span> Which option is selected is left to discussion. One of the <tt>/lib</tt> choices is probably more conformant, but would make these modules accessible from a standard Python shell, which may not be desirable (except for SlicerWizard).
 +
# <span id="fn4"></span> For a standard installation, all products should be installed to <tt>${PREFIX}</tt>; <tt><i>&lt;product&gt;</i>_PREFIX=${Slicer_PREFIX}/lib/<i>&lt;product&gt;</i></tt> is non-standard.
 +
# <span id="fn5"></span> Convention for third party Qt plugins (e.g. see KDE) is a subdirectory (e.g. <tt>plugins</tt>) of <tt>/lib/<i>&lt;product&gt;</i></tt>.
 +
# <span id="fn6"></span> These non-executable files do not belong in <tt>/bin</tt>. While the <tt>.ini</tt> could possible be placed in <tt>/etc</tt>, this requires special handling in the case that <tt>PREFIX=/usr</tt>; <tt>/share/Slicer-<i>&lt;Version&gt;</i></tt> also seems like a reasonable location and does not have this issue.
  
−
Footnotes:
+
Section references in the above are given for [http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf the PDF version of FHS 2.3]. (The HTML version unfortunately does not number sections.)
−
 
 
−
1. 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/... (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. For a standard installation, all products should be installed to ${PREFIX}; <product>_PREFIX=${Slicer_PREFIX}/lib/<product> is non-standard.
 
−
 
 
−
4. Convention for third party Qt plugins (e.g. see KDE) is a subdirectory (e.g. plugins) of /lib/<product>.
 
−
 
 
−
5. 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-${Ver} also seems like a reasonable location and does not have this issue.
 
−
</pre>
 

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.)

Retrieved from "https://www.slicer.org/w/index.php?title=Documentation/Labs/FHSCompliantDirectoryStructure&oldid=37579"