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

[Christian Seiler <christian@iwakd.de>]

On 07/08/2016 10:47 PM, Jakub Wilk wrote:
> * Patrick Schleizer <patrick-mailinglists@whonix.org>, 2016-07-08, 14:18:
>> Would a combined manpage, i.e. 'man corridor', symlinked to the
>> individual command names (corridor-init-forwarding,
>> corridor-init-snat, ...) be acceptable by Debian policy 
> Yes, this is fine.

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?

Regards,
Christian

[1] RFS: https://bugs.debian.org/829242