On 2012-05-10 20:06 +0200, Paul Gevers wrote:
> On 10-05-12 01:22, Ben Finney wrote:
>> Policy dictates, and ‘dpkg’ obeys, that this change is not respected.
>> The result is that the existing directory remains, and is no longer
>> populated in the new release.
>>
>>
>> The package installs a duplicate documentation directory containing
>> identical files to its dependency, so I Think it's best to migrate that
>> to a symlink to the dependency's documentation directory. How can I do
>> that without violating Policy?
>
> Interesting question as I expect that I will face a similar issue in the
> not so far future.
I have faced it a few weeks ago. :-)
> Am I wrong in reading the policy so that it says that dpkg will not do
> this automatically, but as a maintainer, you are allowed to do that
> yourself in e.g. the preinst upgrade target?
Yes, however I would do the conversion in the postinst script to avoid
losing files if unpacking the new version fails. The opposite problem,
converting a symlink to a directory, has to be solved by removing the
symlink in the preinst script.
Everybody seems to do the directory → symlink conversion a little
differently, but what Colin Watson did in the libpipeline-dev package
seemed most reasonable to me, so I followed his example.
Arguably this problem is very common and ought to have a standard
solution, but there seems to be no progress on it¹.
Cheers,
Sven
¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583585
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gwj99lq....@turtle.gmx.de
