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

[Steffen Möller]

On 07/10/2012 03:13 PM, Sascha Steinbiss wrote:
> 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.
Great. This all depends on the scrutiny of your sponsor. Given that it
is too late for Wheezy,
one has time now. But as we all know, a warning that is not fixed early,
only too often
manifests itself too much.
> 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?
Yes.
> Will that be
> enough to make dependents happy which may be linked against a
> libgenometools.so without a soname?
ldconfig should be automagically invoked in the postinst for you
and create the symlink.
> 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...
Since you have everything in one binary, it does not matter too much.
But indeed, I would hope for 1.4.2 of GenomeTools to link to your
own library. You already told me this to be somewhat awkward for some
reason for you, but anyway ..
>> 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?
http://wiki.debian.org/Hardening/
> Do I need additional lintian parameters to see
> them and I missed something?
My version of lintian here is 2.5.8 . Since you check your pbuilder
build on 12.04, this may be slightly differerent. Try passing
 --display-experimental to your lintian installation. Or install lintian
from a later version of Ubuntu, I suggest.
>
>> 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
ah
>  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.
Good to me. Someone else might know better.
>> Kind regards and thanks for working on this package
>>        Andreas.
> Kind regards and thanks for your time helping a newcomer out :)
Time well invested from my perception!

Steffen