On 2016-09-15 10:49, Gianfranco Costamagna wrote:
changes are huge, but being half mia, and on lowNMU threshold...
(and too many bugs here, so lets do it)
First of all, thanks for the detailed review.
I have addressed most issues but not yet uploaded a new version to
mentors, pending a couple of questions.
1) have patches been upstreamed?
Patch 0001 (pkg-config change) comes from the upstream bug tracker and
patch 0002 (empty index.html) has been upstreamed.
Patch 0003 (removal of /usr/bin/cgicc-config, see also below, point 7)
is not, since I see this as a packaging issue rather than an upstream
problem.
2) patch description might be nice
3) d/p/003-no-old-style-config.patch
So, in case please patch Makefile.am
4) automake, libtool, doxygen, dh-autoreconf
doxygen might be needed only for arch:all builds, so you might want to
move
it into Build-Depends-Indep
Fair points, my next upload to mentors will fix these.
5) automake, libtool, are them useful?
They are both used in the build. But if I understand you right, are you
suggesting to drop the explicit dependencies since dh-autoreconf already
depends on automake and libtool? If this is the customary way then I'll
drop the explicit dependencies on automake and libtool.
6) new files
diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.dirs
diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.install
why?
Uh, these files are not needed and are leftovers from my experiments
with a multi-arch library and will be removed in my next upload.
7) /usr/bin/cgicc-config
this was shipped before, why are you removing it?
This file is made obsolete by the pkg-config file, and it was creating a
problem for multiarch packages: it would install in
/usr/bin/cgicc-config, making it impossible to install two architectures
of this package.
Also, https://lintian.debian.org/tags/old-style-config-script.html says:
| Using this kind of system to pass compile file is obsolete and will
likely introduce bugs in a multi-arch system.
| Particularly, this kind of script could only belong to a package that
is not Multi-Arch.
So I took this as excuse to remove the file from the package.
One possible solution (suggested by lintian) is to move the file out of
the way (to /usr/share/doc, I presume) so it is still shipped, but it
won't be found by build tools, which kind of defeats its purpose. I'm
doubtful there is any benefit in shipping this file.
8) library changed soname?
from libcgicc.so.5.0.2 to libcgicc.so.3.2.10
As far as I can see from the CVS changes, the 'current' value in the
soname was increased in the early 2000's, presumably due to ABI changes.
Then in 2013 the soname was decreased from 5 to 3 in order to match the
library version. This was done as part of these bugs:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=38053
https://savannah.gnu.org/bugs/?func=detailitem&item_id=38224
I presume the package should follow the upstream soname. And this would
probably also justify the renamed package, as you were musing in your
mail. If there are no objections, I will rename the packages from
libcgicc5 to libcgicc.
W: libcgicc5: package-name-doesnt-match-sonames libcgicc3
This should be fixed by the renaming from libcgicc5* -> libcgicc*.
X: libcgicc5: shlib-calls-exit
usr/lib/x86_64-linux-gnu/libcgicc.so.3.2.10 (^^ this is something for
upstream)
Raised as https://savannah.gnu.org/bugs/index.php?49120
Thanks,
Thomas
