Hi David,
On Fri, Jun 21, 2013 at 10:37:50AM +0200, David Parsons wrote:
I won't be of a great help for splitting the set of biological
packages since I'm not a biologist either.
I had a question regarding the metapackages (MP for short) however.
Can a MP be included in another MP ? If so bio-ngs could be a
dependency of bio, which would prevent us from having to duplicated
entries...
The idea is not new because it came up in the Debian Science Blend when
there was some interest to include Debian Med's biology packages and
DebiChem packages. However it is not yet implemented (for several
reasons - the main one probably lack of time).
libc6-dev (>= 2.15)
which is fullfilled in testing and unstable but not in stable. So may
be your motivation was to make sure people building the package on
stable get an early warning that something will be broken in the build
process? I did not tried building the package on stable but are you
sure that this is needed? Moreover I think we can drop the version on
zlib1g-dev which is fullfilled even in oldstable.
I think we could get rid of the version on libc6-dev, I wasn't sure
so had put my system's version, that was a bad idea.
Probably not bad - just unnecessary. There are only very few cases
where a versioned libc6-dev is needed. I do not know any such case in
Debian Med scope.
I have seen that you have written a manpage debian/kissplice.1.
If you call lintian iwth information severity on (-I) you will notice
a spelling error. Lintian is also reporting missing manpages of the
other tools. Woould you mind writing also these manpages?
I didn't write manpages for the other executables because they
shouldn't be called directly from the user. The main executable is
actually a python script that calls all the other executables in an
integrated pipeline (with some executions being done in parallel) .
I personally don't like the multi-binary arch very much but I won't
be able to modify this right now. I'll talk about that with the
upstream team.
The best way to fix this would be to move the binaries in question
to /usr/lib/kissplice and adapt the PATH inside the main program.
Given the fact that it is somehow about esthetics I would not call
this a stumbling stone for a first upload, but it would be nice to
have a better design.
Finally the source would be considered as "non-free" because the source
for doc/user_guide.pdf is missing. The best way to fix this is to ask
upstream for the LaTeX source of this documentation. If they do not
want to distribute this source we need to remove the doc from the source
tarball (which would be suboptimal, thought). Given that upstream is
cooperative the doc should also be installed into the binary package -
just mention it in debian/docs.
I'll add the .tex and add it to the binary package
It only needs to be inside the *source* package. It is sufficient to
ship (even the prebuilded) PDF inside the binary, but the source simply
needs to exist.
Thanks a lot !
You are welcome
Andreas.