Re: combined manpage with symlinks to multiple binaries across packages: how to do?

[Sven Joachim <svenjoac@gmx.de>]

On 2016-07-08 23:53 +0200, Christian Seiler wrote:

> If I may piggy-back off here: what's the best way to achieve that if
> this crosses binary-package boundaries?
>
> While packaging open-isns [1], I had the following problem: upstream
> ships a man page isns_config.5, which covers isnsadm.conf.5,
> isnsd.conf.5 and isnsdd.conf.5. But in my case, the programs that use
> these config files are all in separate packages (two of them Depend:
> on the third though). I ship isns_config.5 with the package that the
> other two depend on, and I use dh_link (via .links) to create a link
> for isnsadm.conf.5 to isns_config.5 within the same package.
>
> However, in the other two packages, this doesn't work properly:
>
>  - If I also use dh_link/.links here, the link will be created, but
>    dh_compress will not treat the link because the target doesn't
>    exist within the subtree of the binary package. (It will exist
>    on the system because of Depends: on the other package.)
>
>    This causes the symlink to be left alone, which means it will
>    be left dangling, because the uncompressed target won't ever
>    exist on the system. (Also, lintian complains about an
>    uncompressed man page.)
>
>  - If I use dh_installman's ".so" feature to do automatic linking,
>    dh_installman will not replace the manpage with a link, because
>    it also doesn't see the link target. In that case, I get a
>    plain text file installed that just contains
>       .so isns_config.5
>    Which man doesn't really interpret itself, and which is hence
>    completely useless.
>
>  - If I use dh_link/.links to symlink the .gz variant (which does
>    not yet exist at the time dh_link is run, but will later because
>    dh_compress is run after that), this would work. However, this
>    will break if the compression algorithm for man pages is ever
>    switched - and thus breaks the abstraction of dh_compress...
>
> Currently, I just copy the man page into the other packages with
> the new name, which duplicates a bit of space, and the end result
> is not quite as elegant, but appears to be the only solution that
> is future-proof.
>
> Am I missing something here?

I don't think so, this problem has been noticed some time ago[1].

Cheers,
       Sven


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139020