dicomscope: open tasks
[Sorry for duplicate email, I am trying to get organized]
On Fri, Jan 9, 2009 at 2:41 PM, Andreas Tille <tillea@rki.de> wrote:
<...>
> Here are the remaining issues:
>
> Lintian:
> W: dicomscope: binary-without-manpage usr/bin/dicomscope
>
> -> Would you be able to write a (short) manpage for /usr/bin/dicomscope?
Still todo.
> E: dicomscope: no-shlibs-control-file usr/lib/libjInterface.so
> N:
> N: Although the package includes a shared library, the package does
> not
> N: have a shlibs control file. If this is intentional, please override
> N: this error.
> N:
> N: Refer to Policy Manual, section 8.6 for details.
>
> -> Unfortunately I have not the slightest idea what might went wrong
> here. Perhaps we should ask on debian-{devel,mentors} for help ...
Will do.
> I: dicomscope: arch-dep-package-has-big-usr-share 3304kB 89%
> N:
> N: The package has a significant amount of architecture-independent
> data
> N: in /usr/share, while it is an architecture-dependent package. This
> is
> N: wasteful of mirror space and bandwidth, as we then end up with
> N: multiple copies of this data, one for each architecture.
> N:
> N: See also:
> N:
> http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata
>
> -> It might make sense to provide an arch independent package
> dicomscope-data to reduce disk space and bandwidth of mirrors.
> I did not really made up my mind what might be the best solution
> here. It might perhaps be also reasonable to provide a package
> libjInterface with the dynamic library (to respect
> W: dicomscope: package-name-doesnt-match-sonames libjInterface
> which I would override otherwise) and make the dicomscope package
> containing wrapper, jar, tcl as architecture independent. Could
> you give any hint whether a seprate libjinterface - perhaps with
> a less generic name - might make any sense for other purposes than
> dicomscope?
Is this still an issue ? Should I split the package ?
> Other:
> - README.Debian:
> Please stick to the usual scheme of other README.Debian files (title,
> end with date, length of line < 80 characters), fix spelling.
Fixed.
> - Please clarify how important the provided PDF documentations might
> be for the user. It might make sense to provide a separate
> dicomscope-doc
> package if there might be users who might live without the doc.
If one pdf can be removed it is: /usr/share/doc/dicomscope/dscs360.pdf
This is only required for advanced users.
--
Mathieu
Reply to: