FHS compliance #62

New Issue

claunia · 2026-01-29T16:28:25Z

claunia commented

2026-01-29 16:28:25 +00:00

Originally created by @claunia on GitHub (Jul 7, 2019).

Executables are expected to be in /usr/bin/whatever, /usr/local/bin, et all, while /usr/share is designed to be the place for architecture independent data (see https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html).

Some distros deviate slightly from the FHS but on most it's a sure thing that executables go in /usr/bin, architecture independent data (e.g. a wwwroot from asp.net) goes to /usr/share/<application_name>, and packages that require a specific directory structure (usually because they link to specific versions of libraries, like the Jetbrains tools, AfterShot, et al) install at /opt/<application_name> with a symlink in /usr/bin.

So for .NET Core >=3.0 with SingleFile enabled (see #109) the executable should be /usr/bin/<application_name> while dependent files go in /usr/share/<application_name>/

With .NET Core without single file enable (as of now) they should go to /opt/<application_name> with a symbolic link (or launch script) created in /usr/bin/<application_name>

In the later case this may be an option to not break compatibility, as well as add another option to set between symlink or launch script, and maybe environment variables to be set as part of the launch script.

In any case is the responsibility of the application developer to not assume files would be in the same folder as the executable unless strictly needed (e.g. the /opt case)

Originally created by @claunia on GitHub (Jul 7, 2019). Executables are expected to be in /usr/bin/whatever, /usr/local/bin, et all, while /usr/share is designed to be the place for architecture independent data (see https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html). Some distros deviate slightly from the FHS but on most it's a sure thing that executables go in /usr/bin, architecture independent data (e.g. a wwwroot from asp.net) goes to /usr/share/<application_name>, and packages that require a specific directory structure (usually because they link to specific versions of libraries, like the Jetbrains tools, AfterShot, et al) install at /opt/<application_name> with a symlink in /usr/bin. So for .NET Core >=3.0 with SingleFile enabled (see #109) the executable should be /usr/bin/<application_name> while dependent files go in /usr/share/<application_name>/ With .NET Core without single file enable (as of now) they should go to /opt/<application_name> with a symbolic link (or launch script) created in /usr/bin/<application_name> In the later case this may be an option to not break compatibility, as well as add another option to set between symlink or launch script, and maybe environment variables to be set as part of the launch script. In any case is the responsibility of the application developer to not assume files would be in the same folder as the executable unless strictly needed (e.g. the /opt case)

claunia commented

2026-01-29 16:28:26 +00:00

@qmfrederik commented on GitHub (Jul 11, 2019):

@claunia Thanks for the feedback, it is very much appreciated! I had hoped to look into the issues you raised in the beginning of July, but that unfortunately did not work out.

I'm off on holiday, but will try to look into this in early August.

Sorry for the delay (and thanks for all the help with plist-cil 😄 ).

@qmfrederik commented on GitHub (Jul 11, 2019): @claunia Thanks for the feedback, it is very much appreciated! I had hoped to look into the issues you raised in the beginning of July, but that unfortunately did not work out. I'm off on holiday, but will try to look into this in early August. Sorry for the delay (and thanks for all the help with plist-cil 😄 ).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#62