Bug#985339: nauty: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Torrance, Douglas]

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.