You are not logged in.
heres full PKGBUILD
Is it OK to delete like this from PKGBUILD?
package() {
rm -f $HOME/.cache/angrysearch/angry_database.db
my program creates a database, since its preferable to not run as root it is created in users home directory in ~/.cache/
but during update the new version of the program uses slightly different database, not compatible with the old one
the program is suppose to deal with it on its own, detecting the old kind and prompting generation of a new one.. but still I wonder..
Should I go for deletion in this way? Is it OK approach?
Isnt there a stage in PKGBUILD where I can put it where it gets executed on removal of the package, rather than on building a package?
How about a config file, if I would delete my config file in /.config/... this way, any problems?
to add more to the heaping pile of questions
am I able to track files inside $HOME like I am able to track the others?
by track I mean removal on pacman -R or on update
The files I create and copy around in PKGBUILD, those do get removed on uninstall/update
but stuff gets complicated if I try to do same in home, if I touch a file during PKGBUILD in $HOME it gets owned by root
so normally executed app wont be allow to make changes...
Offline
Is it OK to delete like this from PKGBUILD?
Absolutely *not*. I'm pretty sure makepkg will not even allow that - I sure hope it doesn't. Never touch anything in a user's directory in a PKGBUILD. PKGBUILDs build packages, that's it. There is no reason to believe it is even being built on the machine it will run on.
You could put this in a post install script, this would be functionally appropriate as this runs on the target machine. But if you try to delete anything from user's home folder's without their consent, do not be surprised if your tires get slashed and your car gets egged. I'd use a post-install message telling the user that the file should be removed.
The best solution would be to modify the program to do things in an easier way. If these databases are not actually user-specific, store them in the root directory, under /var perhaps. You can set access permissions so your program can modify them. If they are user specific and need to be deleted with every upgrade of the program, just embed a version number into the database, and check this on program start-up: if the database is in the old format, your program can delete it and create a new one.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Just to reinforce what Trilby has said; definitely do not touch the users home directory in a PKGBUILD, especially do not delete things because weird bugs can do bad things.
Are you familiar with our Forum Rules, and How To Ask Questions The Smart Way?
BlueHackers // fscanary // resticctl
Offline
Thanks for the info, I thought that it felt unnatural to delete on building a package...
I will just let the program deal with the database, detect old one and trigger recreation of the new format.
Offline
You could put this in a post install script, this would be functionally appropriate as this runs on the target machine.
Isn't the post_install() always executed as root, i.e. HOME=/root?
If not it would be even more confusing, since there may be several users.
Offline
Isn't the post_install() always executed as root, i.e. HOME=/root?
Ah, yes, so that wouldn't even work at all. One could `rm -f /home/*/.config/whatever` in a post_install script, and it might work. But this is an equally horrible idea.
Just never touch a users files while packaging or installing.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline