Bug #1430

Fix debian packaging to conform more strongly to debian policy

Added by A. Tuleu over 8 years ago. Updated over 8 years ago.

Status:NewStart date:02/20/2013
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Packaging
Target version:-

Description

I know this is an hassle, but it gives me lot of maintainance nightmare at higher levels because the debian policy is not strongly followed in the debian packaging of librsc.

Please fix the following issues :

  • have a runtime and a dev package.
  • Make sure runtime package have the same full name than the library (with SONAME). Currently it should be librsc0.9
  • No header in the runtime package, but in the dev package
  • No librsc.so in the runtime, but in the dev package a symlink to librsc.so
  • fixed pkg-config file for this setup (no runtime path, and point simply to -lrsc)
  • provide a shlibs file for better debian integration. (see section 8.6). Basically it will be used by dpkg to maintain its database of symbols / shared lib dependency

This come from the debian manual policy, and could causes problem, especially when using pkg-config to symlink with rsc (which is the case for liboncilla compilation from webots).

Please refer to http://www.debian.org/doc/debian-policy/ch-sharedlibs.html

History

#1 Updated by A. Tuleu over 8 years ago

sorry I made a typo. in the dev package librsc.so should be a pointer to librsc.so.0.9

#2 Updated by Anonymous over 8 years ago

  • Status changed from New to Feedback

CPack offers support for some of these aspects, so we might be able to stick to CPack and solve these issues (which I would be in favor of).

For the split-up into dev and runtime package: I did this once for another package with cpack and this was actually quite easy and worked fine. See Component Install With CPack

Since this might have larger impact on existing installations, I suggest to start with an rsc branch testing a split into packages before doing this in master.

#3 Updated by Anonymous over 8 years ago

  • Category set to Packaging
  • Status changed from Feedback to New

I played around a bit in a separate branch wip-debian-packaging and an CI job for it.

It turns out, that the combination of cpack debian generator and cpack components is not powerful enough for our needs. For example:
  • The debian package names of the package components (bin and dev in the test-case) are created automatically as {CPACK_DEBIAN_PACKAGE_NAME}-{COMPONENT}, so that there is always the -dev or -bin suffix in the package name. So having a package with the same name as the library, as requested by lintian, is not possible this way (there is maybe a very ugly work-around, which involves calling cpack manually, but I didn't try this one).
  • Several debian package options are considered for all components, e. g. the shlibs file is inserted in all components, leading to other lintian issues, complaining about an shlibs file in a package without libs (i.e. the dev package)
  • etc. (see lintian plugin in the CI job)

Also available in: Atom PDF