Restructure the file layout to comply to the FHS

[volter]

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.

[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

[volter]

Hi Maris, long time no see!

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

[glynn]

Replying to 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.

[marisn]

Replying to 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 ;)

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.

[glynn]

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

[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

[glynn]

Replying to 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.

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

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after milestone closed