You are not logged in.
I'm trying to write a PKGBUILD for https://github.com/mckset/KD100, however this program expects its default config file to live in the user's $HOME directory, specifically $HOME/.config/KD100/default.cfg. Trying to research how to install the provided config file into a user's home directory only turned up results explaining how bad of an idea it is to touch anything in $HOME from a PKGBUILD, not to mention that it's not really accessible. How should this be handled? Storing config files in $HOME doesn't seem to be that big of a sin, and plenty of configuration files already live there. Presumably if other programs do it there is a sanctioned way of getting configuration files into a user's $HOME directory after an install?
Offline
User config files do belong under ~/.config/ but this location is never packaged. If the program can use a system config it can be installed to /etc, or you can install the config under /usr/share/KD100/ and individual users can move it if they want to use it.
Does the program not actually work at all if there is no config under ~/.config/KD100? That'd be really bad practice for the upstream code - so much so that I highly doubt that this is the case.
EDIT: if no config file is present, the program will exit with a warning instructing the user to put the config file in ~/.config/KD100/ so you're all set. Just include the default config somewhere in the package, I'd recommend /usr/share/KD100/default.cfg.
Last edited by Trilby (2024-06-07 03:47:49)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
When programs need a config in a user's home dir, they need to do it themselves at runtime. There is absolutely no way for a package to do this. If the program really requires that, your only real option would be a wrapper script that checks for it and copies it if missing before launching the program.
Offline
It's on Github and the project has zero open issues. How about a bug report requesting proper config handling? Fork and fix it yourself and request a merge?
You could also output a note regarding the config file at the end of the installation.
Offline
That could be good, though if you take even a momentary glance at the code, there are far more important things to fix. It's only around 500 lines of code so it's not so complex to be hard to fix up - but it's doing the work of about 20 lines of code, so the best fix would be to start completely from scratch.
Last edited by Trilby (2024-06-07 12:09:05)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline