Andrius Merkys writes: > On 2021-03-17 00:51, Andreas Beckmann wrote: >> On 16/03/2021 16.05, Andrius Merkys wrote: >>> symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-1~ >> >> That looks correct. > > Thanks for confirming. > >>> From this I gather that upgrades of nauty <= 2.7r1+ds-1 to this new >>> version should trigger the replacement of a symlink with real directory >>> before placing the files inside. Or am I wrong? >> >> In buster we have >> /usr/share/doc/nauty -> libnauty2 >> but in jessie we had >> /usr/share/doc/nauty -> /usr/share/doc/libnauty2 >> >> and that is not caught by the maintscript entry. > > OK, I see, so the problem is due to jessie -> buster upgrade. > >> The following should catch both cases: >> >> symlink_to_dir /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~ > > dpkg-maintscript-helper(1) says: > > dpkg-maintscript-helper symlink_to_dir \ > pathname old-target prior-version package -- "$@" > > pathname is the absolute name of the old symlink (the path will be a > directory at the end of the installation) and old-target is the target > name of the former symlink at pathname. It can either be absolute or > relative to the directory containing pathname. > > From this I gather that absolute and relative paths are equivalent, but > I may read it wrong. Maybe both have to be added?: > > symlink_to_dir /usr/share/doc/nauty libnauty2 2.7r1+ds-2~symlink_to_dir > /usr/share/doc/nauty /usr/share/doc/libnauty2 2.7r1+ds-2~ > >> I'll try to test that ...
Has there been any progress on this bug? I'm not sure how to reproduce it, but I'd be happy to help in any way that I can. nauty and its reverse dependencies have been marked for auto-removal on Apr. 29 because of it.
