[GRASS-dev] [GRASS GIS] #1610: Restructure the file layout to comply to the FHS

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------
I suppose this topic is not new to you and it's on the to-do-list of many
distribution packagers:

Please restructure the file layout to comply to the file hierarchy
standard.

http://www.pathname.com/fhs/

Many or most GNU/Linux distributions require packages to follow these
guidelines to even be included. Grass was introduced into Fedora at a
time, when quality assurance wasn't as tight as it is today. Nevertheless,
these changes should be made.

The files installed to /usr/lib and subdirectories are the most prominent
violations.

"/usr/lib includes object files, libraries, and internal binaries that are
not intended to be executed directly by users or shell scripts."

For Grass, besides that, it also contains:

  * Translations --> /usr/share/locale
  * Python scripts --> /usr/share
  * Data (icons, fonts, projection data) --> /usr/share
  * Documentation --> /usr/share/man, /usr/share/doc

The arrows indicate where roughly we expect to find this kind of content.

I know, it is probably really hard to get all that working with the
GISBASE environment variable. For Fedora, my approach on the easier part
was, to hardcode the paths for locales and documentation -- replacing
GISBASE.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by marisn):

Just a small question - and what to do with $GISBASE/bin? Pollute /usr/bin
with ~350 applications, that doesn't work when called out of GRASS
session?

Having a app-specific directory with all it's data if it is not possible
to use it's components outside of specific work session, isn't that
uncommon thing. Here's output of ls on my Gentoo system:
{{{
# ls /usr/lib64/R
bin COPYING etc include lib library modules NEWS NEWS.pdf share
SVN-REVISION
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by volter):

Hi Maris, long time no see!

"... and internal binaries that are not intended to be executed directly
by users or shell scripts"

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by glynn):

Replying to [comment:1 marisn]:

> Just a small question - and what to do with $GISBASE/bin? Pollute
/usr/bin with ~350 applications, that doesn't work when called out of
GRASS session?

That could be dealt with by adding the necessary environment variables to
/etc/profile or whatever, so you're never "outside" a GRASS session.

But I'm still included to close this as invalid/wontfix.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by marisn):

Replying to [comment:2 volter]:
> Hi Maris, long time no see!
>
> "... and internal binaries that are not intended to be executed directly
by users or shell scripts"
You too :wink:

Still I would also vote for "invalid", as I don't see any sense in having
an i.e. g.region man page if I can't run g.region command. GRASS already
has the only directly-run application in /usr/bin -> grass to launch a
GRASS session and the rest should be hidden from the outside of GRASS
session in a similar way how it is in the R.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by glynn):

Replying to [comment:4 marisn]:

> Still I would also vote for "invalid", as I don't see any sense in
having an i.e. g.region man page if I can't run g.region command.

Ah; that's one area where I'd disagree. You might want to view manual
pages in a program which isn't a child of the GRASS session (e.g. xman
launched from the desktop).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by volter):

I would like to clarify my point.

I'm perfectly fine with the interal binaries in /usr/lib, because that is
where they belong. I therefore cited from the FHS: "/usr/lib includes
object files, libraries, and internal binaries that are not intended to be
executed directly by users or shell scripts."

Nevertheless, there are architecture independent files in /usr/lib, that
don't belong there:

  * The graphical frontends
  * The translations are used by the various frontends
  * Icons, fonts and projection data
  * Various documentation

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by glynn):

Replying to [comment:6 volter]:

> Nevertheless, there are architecture independent files in /usr/lib, that
don't belong there:

That's because GRASS expects to find all of its files in fixed locations
relative $GISBASE. The default location is /usr/local/grass-<version>, but
can be changed via the --prefix option. Presumably whoever built the
Fedora packages used --prefix=/usr/lib. Personally, I believe that
/opt/grass-<version> would be more appropriate.

GRASS isn't going to move away from the single-directory layout in the
foreseeable future. That's too much work given the limited amount of
manpower available.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:7&gt;
GRASS GIS <http://grass.osgeo.org>

#1610: Restructure the file layout to comply to the FHS
--------------------------+-------------------------------------------------
Reporter: volter | Owner: grass-dev@…
     Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Component: Installation | Version: unspecified
Keywords: /usr/lib | Platform: Unspecified
      Cpu: Unspecified |
--------------------------+-------------------------------------------------

Comment(by volter):

That person is me at the moment.

/opt is not for distribution packages, but for software the local
administrator installs.

I understand your concerns about manpower. Please consider it anyway in
the long run.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1610#comment:8&gt;
GRASS GIS <http://grass.osgeo.org>