Re: Introduction
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.
--
http://fam-tille.de
Reply to: