You are not logged in.

#1 2022-11-13 01:52:30

D3vil0p3r
Member
Registered: 2022-11-05
Posts: 11

PKGBUILD - How to manage the upgrade of packages impacting $HOME

Hello,
I'm curious to understand how packages as zsh, that place dot files (i.e., .zshrc) in the $HOME folder, work.

pacman must not be used to impact on home folder of current user, and it is not possible directly to copy files to $HOME folder by the PKGBUILD directives. So, how packages as zsh are able to create or update dot files as .zshrc that are stored in the $HOME folder?

If I would like to replicate the same behavior in a new package to be created, how it is possible to do?

In my mind I have different strategies:
1. In PKGBUILD I copy files in /etc/skel and, when I installed the package, I copy manually the files in /etc/skel to the $HOME folder
2. In PKGBUILD I use install=script.install where script.install contains a command like cp /etc/skel/.mydotfile $HOME/ inside the post_install() function
3. Implement a script that the user calls each time he/she wants to sync /etc/skel with his/her $HOME folder by simply copy and paste /etc/skel content

Among the three options, what could be the cleanest one? Is there a further cleaner strategy?

Furthermore, in case I would implement the 2., if I install the package on an ISO by Archiso where a user is still not defined (so in a chroot environment), the $HOME folder specified in the post_install() function of my example will correspond to the /root folder?

Offline

#2 2022-11-13 02:09:40

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 6,859

Re: PKGBUILD - How to manage the upgrade of packages impacting $HOME

Why do you think any packages place files in $HOME? Packages can put files in /etc/skel, as you say, but that only affects home directories created later.

As it happens, zsh doesn't install anything into /etc/skel either:

$ pacman -Ql zsh | grep '\(skel\)\|\(home\)'

You absolutely shouldn't do (2). It is not your business to overwrite dot files in users' home directories, which are very likely to be customised.

(3) is also a bad idea. At most you should offer a script to replace your package's files in the $HOME directory, but if your package depends on such syncing, why have files in $HOME in the first place? The whole point of having configuration files in $HOME is so that a user's configuration can diverge from the system's. If your package doesn't support that kind of divergence, there's no reason to have files in $HOME.

(1) is an option, but if people have to do this to use your package, I don't know why it puts files in /etc/skel.

Note that you shouldn't overwrite files in /etc/skel if they've been modified, either. You either want the .pacsave or .pacnew functionality, so you're not overwriting the local system's configuration. Again, if your package doesn't support local divergence, don't put files in /etc.

Last edited by cfr (2022-11-13 02:14:05)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#3 2022-11-13 02:33:49

lfitzgerald
Member
Registered: 2021-07-16
Posts: 110

Re: PKGBUILD - How to manage the upgrade of packages impacting $HOME

I believe that zsh actually has logic that checks your configs. If none are detected, it prompts the user to initialize configuration. There's an example in https://linuxhint.com/configure-setup-zshrc-zsh/ just before "Configuring ZSH". So it is robust to the package manager failing to create files in $HOME; this is probably the easiest approach for you.

Offline

#4 2022-11-13 02:50:34

D3vil0p3r
Member
Registered: 2022-11-05
Posts: 11

Re: PKGBUILD - How to manage the upgrade of packages impacting $HOME

cfr wrote:

Why do you think any packages place files in $HOME? Packages can put files in /etc/skel, as you say, but that only affects home directories created later.

You absolutely shouldn't do (2). It is not your business to overwrite dot files in users' home directories, which are very likely to be customised.

(3) is also a bad idea. At most you should offer a script to replace your package's files in the $HOME directory, but if your package depends on such syncing, why have files in $HOME in the first place? The whole point of having configuration files in $HOME is so that a user's configuration can diverge from the system's. If your package doesn't support that kind of divergence, there's no reason to have files in $HOME.

(1) is an option, but if people have to do this to use your package, I don't know why it puts files in /etc/skel.

Note that you shouldn't overwrite files in /etc/skel if they've been modified, either. You either want the .pacsave or .pacnew functionality, so you're not overwriting the local system's configuration. Again, if your package doesn't support local divergence, don't put files in /etc.

Thank you for the answer @cfr

Just now I read your edited post about zsh, and also the answer of @lfitzgerald and yes, just now I tested that zsh gives the possibility to create the dot config file when the user runs zsh for the first time. I'm noting also other packages like fish or kitty have the same behavior. So, the right approach should be that the config files on the $HOME folder must be created only when the current user runs for the first time the application.

Thank you for your clarification @cfr @lfitzgerald

Offline

Board footer

Powered by FluxBB