Debianization refactored

Created by: vitalyisaev2

Hello, Danil! Please consider merging this patch. It provides fixes for some problems with distribution of your library on Debian-based platforms. Unfortunately, handystats library was debianized in a quite strange way. The most confusing error is missing of SOVERSION in the library's file name.

In our team we currently have more than 10 С++ projects that link against handystats. As you know, in the end of build process (initiated with debuild command) dh_shlibdeps macros starts in order to derive binary dependencies for the fresh deb package. So every time we build these project, this kind of error appears:

dpkg-shlibdeps: warning: can't extract name and version from library name 'libhandystats.so'

That's because *.so files are usually just a symbolic links on debian systems. System-wide shared libraries have other naming conventions (you can find details here). This results in missing Depends: content of our own deb packages that depend on handystats.

Changes:

1. cdbs is replaced with debhelper;
2. Main package is renamed according to the Debian conventions;
3. libdevel and debug packages are added;
4. SOVERSION is handled properly;
5. Library version is mentioned in CMakeLists.txt and symlinks;
6. License errors and warnings is fixed;
7. TARGET_LINK_LIBRARIES is complemented.

Please note that the package is renamed, so it will affect all the dependent projects (if they are built under Debian platform of course).

Created by: shindo

Hi!

I totally agree that we had messed up with the packaging and I wanted to change it, but couldn't do so due to the necessity of the package renaming as you mentioned. But we are ready to start moving in the right direction.

The plan is as follows:

1. I will create 'v1' branch that will contain the current state of Handystats and will support it for some time
2. 'master' branch will contain Handystats version 2 with updated packaging

But there're several other changes I want to see in Handystats version 2:

• version numbering follows X.Y.Z scheme starting from 2.0.0, thus SOVERSION will be 2
• devel package should include SOVERSION in its name. You can take a look at https://github.com/reverbrain/swarm/issues/28, where I described my thoughts on this
• all packages should conflict with old handystats package (or we should provide dummy handystats=2.0.0 package as a transitional one, let's think about it)
• RPM packaging is updated as well
• Archlinux packaging is removed
• copied RapidJSON headers are removed from Handystats' public headers (internal implementation should use https://github.com/shindo/librapidjson):
  • either we use librapidjson and support HANDY_CONFIG_JSON from RapidJSON object and dumping metrics to RapidJSON object
  • or we remove dependency on RapidJSON from the core library and provide additional package with dumping helpers (libhandystats-json, or smth like that)
• (optional) we should provide CMake module to find Handystats via FIND_PACKAGE (Handystats)

It would be great if you could update the pull request according to the described requirements on Debian packaging or even help us on updating RPM, removing Archlinux packaging and getting rid of RapidJSON headers, I would appreciate it a lot!

You can take a look at v2.1.0 branch where I tried to do the packaging right: https://github.com/yandex/handystats/tree/v2.1.0

You can take a look at Swarm/TheVoid packaging, where versioned devel packages are used: https://github.com/reverbrain/swarm

Once again thanks for your contribution!

Created by: vitalyisaev2

@shindo, you are welcome :) To be honest, I didn't know about the plans onto v2.1.0 branch. I guess our team is missing the point as well.

I looked through the debian in v2.1.0 and well... it looks just perfect. I've never done such complex things with debian before, so I would prefer just studying this example rather than contributing to them (at least at the moment).

Regarding rapidjson... It's a difficult question too. We discussed them half a year ago. We're packaging rapidjson for our own purposes with CPack, and I know it's not a good practice. Since you have already introduced librapidjson and you have the upstream vendored inside it, I will make an effort to replace our CPacked debs with yours. From my point of view future libhandystats2 package should depend on librapidjson package, because rapidjson is a library that has a lot of use cases.

The only thing I can offer you with the current PR is to simplify debian/control in v1 in order to preserve package name but distribute the library with the SOVERSION. This fix will solve our build problems and (hopefully) will not break anything else. Please consider the latest commit.

Created by: shindo

Sorry, I didn't explain the current state of the branches clearly.

All v2.X.X are stalled branches and were not updated for a year. It was my attempt to fix packaging and add some new features (like python bindings), but the decision was to "backport" these features into the master branch step by step and keep backward compatibility.

I like the idea to add versioned .so (with SOVERSION 1), but we should verify that this will not break things, otherwise we have to do this (adding versioned .so) accompanied by SOVERSION bump (it will be 2).

Right now with your pull request handystats package will contain:

• libhandystats.so -- symlink to the API-versioned .so
• libhandystats.so.1 -- API-versioned .so, symlink to "build"-versioned .so
• libhandystats.so.1.11 -- "build"-versioned .so

Already built libraries/executables (call it libOLD) linked with "old" handystats package have the following in their dependencies (one can check it with objdump utility):

  NEEDED               libhandystats.so

ldd resolves the dependency in the following way:

libhandystats.so => /usr/lib/libhandystats.so

/usr/lib/libhandystats.so is provided by the "new" handystats package, thus is presented in the system and everything should work.

But what if we have some library (call it libNEW) built and linked with the "new" handystats package? Linker will look at libhandystats.so that is symlink to libhandystats.so.1, I suppose objdump will show the following:

  NEEDED               libhandystats.so.1

that ldd should resolve in the following way:

libhandystats.so.1 => /usr/lib/libhandystats.so.1.11

I'm not sure if an executable linked with both libOLD and libNEW will work. Will it have two NEEDED sections with libhandystats.so and libhandystats.so.1? And If so, will the actual library (libhandystats.so.1.11) be loaded twice? Are there any other cases that may fail?

These questions are important and interesting, but to be honest I think that major version bump along with packages renaming will do the thing better. Still I will think on these questions and try to check it.

Created by: vitalyisaev2

@shindo now I see that the problem is much more complicated than it seems at first sight... Let's postpone this discussion until the moment when we will be able to evaluate all the risks. Thank you for a very detailed explanation!

closed

Created by: shindo

Sure, we should investigate the issue further.

I will leave the pull request open if you don't mind, as it may happen that there's no problem with your changes and we can merge them safely.

reopened

Merged by: shindo at 2016-06-01 21:04:01 UTC

merged manually

closed