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

[Andreas Tille]

Hi Sascha,

On Tue, Jul 10, 2012 at 03:13:43PM +0200, Sascha Steinbiss wrote:
> > 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.

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

You might like to have a look at *any* library package:  The unversioned
*.so file is a symlink to the versioned *.so.x file in the non-dev
package.  That's how it works and you can trust lintian here.

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

No, it is not.  I just wanted to make sure you have somehow realised
this as some todo item.  I would not mind about an initial upload
without a manpage.  However, if you said you have some way to generate a
manpage for an upcoming version - is it terribly wrong to just move the
result of this process to the debian/ dir and install from there?  Just
answer either yes or no and I will do the sponsoring without questioning
your decision.

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

Sounds perfectly 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?

   http://wiki.debian.org/Hardening
 
> > 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.

Well, at least you tried to solve this :-) - but it is a bit invasive
patch and can not be applied upstream in general (for those rare cases
where users do not use Debian ;-)).  The proper patch would be that the
upstream Makefile should regard CFLAGS CPPFLAGS and LDFLAGS set
externally.  The `dpkg-buildflags --get <something>` should be done
in the debian/rules file and not in the upstream Makefile.

Once writing this I come back to one of my previous remarks about
debhelper:  If you have no strong reasons to not use debhelper 9 please
simply use it and the according variables are set in the rules file
anyway without any additional things to do.

Kind regards

        Andreas.

-- 
http://fam-tille.de