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

[Sascha Steinbiss]

On 07/10/2012 07:30 PM, Andreas Tille wrote:
> Hi Sascha,

Hi Andreas,

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

Okay, I moved the symlink to the dev package.

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

Good idea. I just implemented and committed this. I will just need to
remember changing the paths later on to use the always up-to-date
manpages from the upstream tarball.

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

I see. Our Makefile actually already does respect external CFLAGS,
CPPFLAGS and LDFLAGS, only appending some of our own flags (see below).

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

Okay, I just noticed there is a debian/compat file, containing the
compat level. I kept asking myself "Okay, I will try debhelper 9, but
how DO i use it?" ;)
Now I have changed it to 9 and adjusted the build-depends to require
debhelper 9. I also disabled the stuff we set in our Makefile to
respect what the externally set CFLAGS say, e.g. it does not set its own
-Werror and -O3 anymore.
I had a look at the compiler calls to verify that what dpkg-buildflags
outputs is in there. So it seems like we got it, right?

Lintian (2.5.10 from unstable) seems to be happy now.

> Kind regards
> Andreas.

Kind regards
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