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

Reply via email to