[aur-general] Fixing a package with broken config symlinks

[Gordian Edenhofer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20150603/78046e35/attachment.asc>