On Wed, 2015-06-03 at 09:28 +0200, Florian Bruhin wrote:

Hi,

I inherited a package (agendav) for a webapplication which had the config symlinking backwards. This means:

- The real config files were installed into /usr/share/webapps/foo - /etc/webapps/foo is a symlink to /usr/share/webapps/foo - backup=() in the PKGBUILD only lists etc/webapps/foo

I'd like to correct this situation in an update, but that update will of course overwrite /usr/share/webapps/foo with the new version (i.e. the new symlink) and nuke the user's current config.

I tried adding both the etc/ and the old usr/share path to backup=() in the hope that pacman would create a .pacsav on update, but that didn't help:

https://github.com/The-Compiler/pkgbuild/blob/master/agendav/PKGBUILD

diff to the broken version: https://github.com/The -Compiler/pkgbuild/commit/f5af712f76a7ed5d0869130f1f7f9da69541462b

Currently when I update, this happens:

- /etc/webapps/foo is a broken symlink because it links to /usr/share/webapps/foo (which now links to /etc/webapps/foo). - The template config from the package is installed to /etc/webapps/foo.pacnew - /usr/share/webapps/foo is now the (correct) symlink to /etc/webapps/foo - The user config in /usr/share/webapps/foo got overwritten by that symlink without a .pacnew or .pacsav (why? Is there something I did wrong?).

Is there any way I could fix this mess without deleting the user's config?

If you want to experiment, you can get the current broken version ( -2) from the AUR, and the "fixed" one (-3) from the git repo above.

Thanks,

Florian

I was faced with a somewhat similiar problem once and solved it in the .install file. Guess this is not the best way but at least it worked. First of all you should place the new config file in /etc/webapps/foo and do not create a symlink to it. Now switch to your .install file and check whether /usr/share/webapps/foo is not a symlink in the post_upgrade function. If so than move the file to /etc/webapps/foo and create the symlink. At this point I think it would be appropiate to let the user now of the move. However if /usr/share/webapps/foo is a symbolic link than you can be sure that the user was already migrated. In the post_install function you can either just use the same script or simply create the symlink from /usr/share/webapps/foo to /etc/webapps/foo since one can assume that in this case the package gets installed for the first time. For users who rarely update their servers I would recommend leaving this script in your .install file for a while. When using this method keep in mind to remove the symbolic link in the post_remove function! Pacman will not detect this link as a property of the package because it was not contained in the package file itself. Best regards, Gordian