You are not logged in.

#1 2019-02-09 10:26:41

apollo22
Member
Registered: 2018-04-13
Posts: 34

Path for user written files

Hi everyone,

I have been looking for the correct path of the files I write myself for a few months now, and I am still wondering a few things. So here are my thoughts on this:

Files distinctions

So far, I believe there are a five kinds of files for userland usage:

  1. Files installed by the distribution package manager [ DPM ] 

  2. Files installed locally, installed by a specific package manager (for exemple pip) [ SPM ] 

  3. Files installed locally, using a drop-in folder [ DIF ]

  4. Files installed locally, installed manually by the administrator (using make for exemple) [ AMI ]

  5. Files created by the users [ UC ] 

Then, the files can either be for the whole system, or for a specific user.

From what I could gather, only files of type 1, 2 and 3 have their dedicated path. And even so, files of type 2 are mixed between package manager :

  1. System files

    1. [ DPM ] /usr/

    2. [ SPM ] /usr/local/

    3. [ DIF ] /opt/

    4. [ AMI ] Undefined (Resort to /usr/local/

    5. [ UC ] Undefined (Resort to /usr/local/ 

  2. User files

    1. [ DPM ] Not used

    2. [ SPM ] ~/.local/

    3. [ DIF ] Undefined

    4. [ AMI ] Undefined

    5. [ UC ] Undefined (Some resort to ~/bin for scripts, others to ~/.local/bin )

Should the Distribution Package Manager install anything in user directories ?

Question 1: Do you think I made any mistakes in this distinction ?

Question 2: Do you believe such a deep distinction should be made ?

Question 3: Do you think dropping the /opt, and using a /usr/local/dif would be a good idea ?

Specific Package Manager path distinction

I think separating path for each package manager prevents corruption, but it can lead to mismatched versions. In this case, how should files be prioritised ? (User Created Files take precedence)

Per Specific Package Manager folder also means those paths have to be added to your shell and in some programs (systemd).

One solution for the shell could be to use a SPM configuration file, used by a sourced script adding the new paths. Each SPM would then just add the paths it uses in the configuration file, without disturbing other SPM.

User created files

For the files created by the system administrator, how about treating them as a Drop-In folder, and creating the /opt/diy (work has to be done on the name smile ) folder ? The other solution would be to create a dedicated folder in /usr, like /usr/diy

The same would apply to the user created files, that would be in ~/.local/opt/diy, ~/.local/dif/diy/, ~./opt/diy/ or ~/.local/diy, depending on the previous choices.

Conclusion

I know this is a very disturbing concept. Please consider the following: how would you do this in the current paths usage, and how would you do it in an ideal filesystem (as in, you do not care about the history, nor the current usage) ?

Do you believe any of my proposal are interesting ?

In any case, do you have any comments on this ?

EDIT: Sorry about the first post, I misclicked the Preview button

Last edited by apollo22 (2019-02-09 11:47:52)

Offline

#2 2019-02-09 11:02:07

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: Path for user written files

Your post is missing the "types" you refer to… but anyway, you're referring to non-packaged files, and there is some form of standard (mostly).

For systemd unit files, there's actually a lot of places, so it depends what you want. But for persistent units (i.e. the ones not in /run), AFAIK they are not "mixed" with the package manager (no package places files in /etc/systemd, and definitely no package touches your personal $XDG_CONFIG_HOME/systemd).

Executables can go anywhere you want, as long as you add the directory to $PATH. However, for system-wide executables the convention is to put (unpackaged) files in /usr/local/bin (actually, unpackaged files in general end up in /usr/local/{somewhere}). For personal scripts, people usually create ~/bin, ~/.bin, ~/scripts, ~/.scripts, etc. (I personally prefer ~/.local/bin); there is no standard there.

Relevant man pages: hier(7), file-hierarchy(7), systemd.unit(5)

___

EDIT: Oh well, there's your edit.

Question 1
I think the case of "installing files system-wide with a second package manager" should be avoided. As you have noticed, you may run into all sorts of misbehaviour. For pip, I think the solution is to install to user-specific directories and/or user pipenv (I don't have the necessary knowledge to explain that).

Question 2
/opt is for software that doesn't properly follow the FHS and has to be dropped into a "bundle" directory, conventionally /opt. But you will notice that distribution packages may as well install things into /opt, so it doesn't actually distinguish anything there.
Furthermore, some cases don't really apply. The case of a package manager or system administrator installing files into users' homes should never happen. Neither should the case of a user installing files system-wide.

Question 3
Definitely! This is IMHO the major shortcoming of the XDG basedir spec: instead of defining some symmetry with the FHS (and thus simplifying things), they came up with a very crippledlimited specification that only distinguishes between 4 types of files.
I have personally "extended" the XDG basedir spec by adding XDG_LIB_HOME, XDG_LOG_HOME and XDG_STATE_HOME. You may find on the Web that some people do the same. But it's unfortunately not really formalised anywhere.

Question 4
AFAIK systemd doesn't use any "scripts" (I'm even under the impression that systemd tries to get rid of scripts entirely), and if it does, I'm pretty sure they don't end up in /etc.
I personally put my personal executables in ~/.local/bin. System-wide stuff goes into /usr/local/bin, as per the standard. However, I generally package everything that happens system-wide, so I don't realistically run into any "unpackaged system-wide files" situation.

Question 5
I don't really understand that question…

In general, there are very few specifications or standards that target the user home directory. The XDG basedir spec is AFAIK the only somewhat widely adopted specification; the rest is up to the user (or application developer).

___

EDIT 2: Oh, there is another edit. You know what, please make up your mind, I don't want to spend time adapting my post everytime. Have a nice day.

Last edited by ayekat (2019-02-09 11:41:35)


pkgshackscfgblag

Offline

#3 2019-02-09 11:31:46

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Path for user written files

Should the Distribution Package Manager install anything in user directories ?

For pacman & arch linux the answer is NEVER install to user directories.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#4 2019-02-09 15:32:49

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,442
Website

Re: Path for user written files

apollo22 wrote:

... Files installed locally, installed manually by the administrator (using make for exemple) [ AMI ]

These shouldn't exist in arch.  Ever.  Period.  Use a PKGBUILD.

In theory, with a compliant makefile, you could do a `make DESTDIR=/opt/ install` but that may not always work.  So just use a PKGBUILD, that will always work.

Other than this, I don't see your different categories of files as a useful division.  Are you talking just about binaries/scripts?  Or are you asking where user-created documents should go?  (XDG kinda' addresses the latter, but it's all under $HOME, so the user can do whatever they want).

Personally, my scripts are in ~/code/bin/ which is added to my PATH for interactive shells.

Last edited by Trilby (2019-02-09 15:37:47)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#5 2019-02-14 03:20:59

/dev/zero
Member
From: Melbourne, Australia
Registered: 2011-10-20
Posts: 1,247

Re: Path for user written files

I install a lot of stuff under /usr/local using the package users system designed for Linux From Scratch: http://www.linuxfromscratch.org/hints/d … kg_man.txt

It's good for putting software you want to compile from scratch for whatever reason.

I disagree with Trilby here. Since pacman never touches anything under /usr/local, the two forms of package management are orthogonal. I use pacman for my base system, for packages that I need to always work reliably. Under /usr/local can go all the packages which are experimental or optimised just the way I like them.

For example, Vim is a good candidate for going under /usr/local because it has a lot of configuration flags, and I like to choose exactly which ones are enabled. I still have Vim installed in the usual way by pacman in case my custom build breaks.

Another good candidate for putting under /usr/local is libressl, since Arch Linux hasn't switched to it yet wink

Offline

Board footer

Powered by FluxBB