[Debian-med-packaging] r11665 - trunk/packages/genometools/trunk/debian

[Sascha Steinbiss]

On 07/09/2012 08:57 PM, Andreas Tille wrote:
> Hi,

Hi all,

Thanks Andreas for having a look at the package!

[...]
> I found some quite easy to fix lintian warnings
> 
> W: genometools source: dbg-package-missing-depends genometools-dbg
> W: genometools source: syntax-error-in-dep5-copyright line 25: Continuation line outside a paragraph.
> W: genometools-doc: package-contains-vcs-control-file usr/share/doc/genometools-doc/devguide/.gitignore
> W: genometools-doc: package-contains-vcs-control-file usr/share/doc/genometools-doc/manuals/.gitignore
> W: libgenometools0: shlib-without-versioned-soname
usr/lib/libgenometools.so.0 libgenometools.so
> W: libgenometools0: package-name-doesnt-match-sonames libgenometools

Thanks for nudging me... I was aware of these warnings, but did not
consider them showstoppers. Anyway, I just fixed these and committed the
fixes.

Two warnings still remain:

> I consider the following warnings a bit more harder to fix but I think
> it should at least be discussed somehow (I have not noticed any call for
> help to solve this):
>
> W: libgenometools0: non-dev-pkg-with-shlib-symlink usr/lib/libgenometools.so.0 usr/lib/libgenometools.so

Hmm. From the lintian page describing that warning, I guess I should
only include the .so.0 file in the libgenometools0 package? Will that be
enough to make dependents happy which may be linked against a
libgenometools.so without a soname? Some non-packaged applications
dependent on libgenometools are linked that way, since I did not know
about sonames until I started packaging.
However, I cannot estimate how much of a problem that would even be,
since we also provide statically linked binaries for them, requiring no
separate libgenometools installation. Maybe no one will ever notice...

> W: genometools: binary-without-manpage usr/bin/gt

I have just finished a script which creates man pages from the on-line
help (`-help') using asciidoc and will incorporate the files created by
that into upcoming upstream releases. Is it a big problem not to have
them included in the initial upload?
The `gt' binary is used to run multiple tools with different option sets
etc. I have reflected this in the man pages in a way similar to the way
git handles these, by including a man page for each single tool, e.g.
`gt select' gets the manpage 'gt-select.1'. I hope this is ok.

> I have not verified whether the hardening related warnigs are
> correct or some false positives.

What hardening issues? Do I need additional lintian parameters to see
them and I missed something?

> Finally, I wonder whether debhelper compatibility level 7 is intended -
> this is somehow related to the hardening issues.  If possible take
> compat 9 and have hardening automatically.  If you have real reasons
> to stick to 7 please explain and follow the advise about hardening in
> Debian Wiki.

I must admit I am not an expert on debhelper... I have read
http://wiki.debian.org/HardeningWalkthrough to get an idea of the
hardening stuff though.
Would patching the Makefile to add `dpkg-buildflags --get CFLAGS`
`dpkg-buildflags --get CPPFLAGS` to the CFLAGS used for compiling be
sufficient or are we talking about different things? I just did this,
see repo.

> Kind regards and thanks for working on this package
>        Andreas.

Kind regards and thanks for your time helping a newcomer out :)
Sascha


-- 
Sascha Steinbiss
Center for Bioinformatics
University of Hamburg
Bundesstr. 43
20146 Hamburg
Germany

Email:  steinbiss at zbh.uni-hamburg.de
URL:    http://www.zbh.uni-hamburg.de/steinbiss
Phone:  +49 (40) 42838 7322
FAX:    +49 (40) 42838 7312