[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can't open man1/optin.so: No such file or directory

> Hi there,


>  I am working on the dicom3tools package. The dicom3tools is writing
> the man page using groff '.so' macro (source) (*). Which leads to the
> following lintian warning :
> W: dicom3tools: manpage-has-errors-from-man
> usr/share/man/man1/andump.1.gz  can't open man1/optin.so: No such file
> or directory
> ...
> W: dicom3tools: manpage-has-errors-from-man
> usr/share/man/man1/rawtodc.1.gz  can't open man1/genin.so: No such
> file or directory
>  Because the naming convention of those common parameter is bla.*so*,
> lintian is not happy to install something called optin.*so*.1 in the

These are accepted (for instance: vsftpd.conf.5), what is not accepted is 
uncompressed manpages or a missing files referenced for inclusion by other 
manpages, which are actually incomplete when parts of them are missing.

> man1 path. Has anyone dealt with this before ? Can I simply rename
> optin.so file to optin, and then install optin.1, or am I missing
> something with groff ?
> Ref:
> http://svn.debian.org/wsvn/debian-med/trunk/packages/dicom3tools/trunk/
> Thanks,
> --
> Mathieu
> (*)http://www.schweikhardt.net/man_page_howto.html

There is no easy way for dh_installman to guess that optin.so as found in 
source directory is actually a manpage content meant for inclusion, so you 
should take the control yourself and install that files in place from 
debian/rules either by copying it or by calling dh_install + 
<binary_package>.install file containing something as follows:

path/to/optin.so   usr/share/man/man1

However there are two issues here: 

* optin.so should not be compressed since it is referenced to by other 
manpages as `optin.so' as I see it, thus you should also call  dh_compess -
Xoption.so -Xgenin.so and so on... in order to prevent that.

* lintian would later complain that your package actually provides an 
uncompressed manpages, since optin.so and friends are left in place 
uncompressed as they are referenced that way. You can of course override this, 
however I don't think that populating /usr/share/man/man1/ with random named 
uncompressed files meant for inclusion is a sane way to go or at least that 
would need a discussion and conventions agreed upon. A better solution would 
to include compressed manpage files, however I'm not sure if that is at all 

pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>

Reply to: