Re: dicomscope: open tasks

[Andreas Tille <tillea@rki.de>]

On Wed, 21 Jan 2009, Mathieu Malaterre wrote:

> >  Lintian:
> >   W: dicomscope: binary-without-manpage usr/bin/dicomscope
> >
> >     -> Would you be able to write a (short) manpage for /usr/bin/dicomscope?
>
> Still todo.

Fine.

> >   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.

Have realised the advise to consult mentors on devel (I do not read
mentors - keep me informed if something interesting / unclear happens).

> >   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 ?

I'm always in favour of splitting but you are the expert which split makes
more sense.

> >   - 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.

--> dicomscope-extra-docs package?

Kind regards

        Andreas.

--
http://fam-tille.de