I'm more concerned that it cannot be done robustly, therefore should not be done. (Again, running instances. This is usually the reason Arch doesn't move unpackaged data around, or run db migrations for possibly-running services.)
Not that it could be done but shouldn't because they might prefer a broken package that no longer looks in /etc for data.
User's might already be interacting with the file in it's current location. Perhaps it's part of their system backups, or dot-file respository, etc. This is why I'd advocate for informing the user, and letting them move the files as desired.
]]>You can see in my version of the PKGBUILD I already fixed it. https://github.com/starquake/thelounge-archlinux
So now comes my next question: What should I do with the sqlite files (among others) that are left when I move the files using the change in the PKGBUILD?
If people upgrade old files remain in the old location. I have no idea how to fix it and searching did not yet leave me with an answer.
]]>Anyhow, it looks very easy to configure - just modify one line in the PKGBUILD and one in the service file.
]]>When I wanted to install it again I found there was an AUR package now. I installed it but I saw it creating all kinds of files in /etc like sqlite databases and other stuff that doesn't belong there.
This is the AUR package I'm talking about: https://aur.archlinux.org/packages/thelounge/
I saw comments about it on the AUR package but no solutions. Someone mentioned creating an issue. So I did. I also contributed a possible solution.
This is the issue:
https://github.com/thelounge/thelounge- … /issues/18
TL;DR: I want no sqlite database in my etc as the Arch package guidelines suggest. Upstream does not agree. At least not yet as of writing.
Any suggestions what I should do?
Stop moaning because it is okay as it is
Post an alternative PKGBUILD
Something else?
Suggestions welcome!
]]>