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

Re: Introduction



Hi Andreas,


Le 18/06/2013 10:38, Andreas Tille a écrit :
Hi David,

On Mon, Jun 17, 2013 at 11:59:26PM +0200, Andreas Tille wrote:
I suppose I've misunderstood something. Am I not supposed to "add
the package to the “task”file where it fits the best" ?
Don't worry - I can easily add it.  You are no member of the Blends team
which is no real harm if you just want to add this single package - I'll
do it tomorrow.
Done to bio and bio-ngs.  Remark:  Bio-ngs is currently a subset of bio
which is only rendered at the web pages but not turned into a
metapackage.  This is somehow questionable but we did not yet found a
reasonable solution how to reasonably split up the whole set of
biological packages.  I personally feel unable to do this in a
reasonable manner because I'm no biologist (I'm physicist by profession)
and so far nobody took over the work to find a reasonable split.  The
bio-ngs and bio-phylogeny tasks are some first try to experiment with
some more fine grained tasks but if we miss to inject a package into
(main) bio it will not create a metapackage dependency.  Feel free to
make some suggestions how we could enhance this situation.

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


Also, should I svn-buildpackage now or am I done ?
Please try whether the package builds nicely.  It is a good idea
to doe this with pdebuild to make sure that all build-depends are
correct.  I will check the package and will upload or come back
to you with some things that should be changed.
As promised I had a look into your packaging.  You can find some commits
which I would like you to inspect.  The main thing I fixed was the
debian/watch file that did not worked.  I also bumped debhelper to
version 9 to get automatic hardening options switched on.  If you have
good reasons to stick to version 8 feel free to revert this change.

I'm a bit unsure about the versioned Build-Depends

   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.


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.


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


Finally I added a debian/upstream file[1] containing the publication
data.  BTW, you can find a skeleton for an upstream file (as well as
most other files adapted for Debian Med - so you do not need to deal
with dh-make boilerplates) in SVN[2].

Kind regards

       Andreas.

[1] https://wiki.debian.org/UpstreamMetadata
[2] svn://svn.debian.org/svn/debian-med/trunk/package_template


Thanks a lot !
David



Reply to: