[RFC] Add strict versions to shlibs #426
Conversation
bloom doesn't create separate library packages according to the Debian policy naming scheme. As we allow ABI breakage in the release (see Moveit), this results in too lax dependencies for example: Depends: ros-kinetic-moveit-core instead of (for example) Depends: ros-kinetic-moveit-core (= 0.9.6) Resulting in a library not found when the library name changes. This adds strict dependencies for all packages containing shlibs. More discussion: ros-planning/moveit#497
jspricke
changed the title
|
I've only done basic testing of this, but based on the moveit discussion and the limitations of bloom, I think it's the best we can do. Comments welcome. |
|
I haven't used bloom so far, but I assume we do not have any information about the libraries and their so-name we are packaging? If that's the case I think this is as good as it will get (unless we want to rewrite/extend dh_makeshlibs) +1 (note: I haven't tested it myself) |
|
I'd have to defer to @tfoote, but my understanding is that we don't automatically add the version dependency so that non-ABI breaking changes don't require downstream packages to reinstall. There were several discussions on how to specify the ABI version of a package in addition to the normal version number, but there was no consensus due to a hang up on how to separate SO versioning with package "ABI". So bloom can't do anything about this until that is specified (outside of what you've proposed here).
Seems to me you'd have the same problem with ABI breaks and lax versioning whether or not there is a separate library package or not. Maybe I'm missing some as to how having the separate library would address this issue implicitly. It looks like this is a symptom of them (the moveit developers) using SO versioning, which changes the library name for each release. If that's the case then I think they can add I don't mind adding this to the default bloom rules file template as long as there is no regression for existing packages or other drawbacks. I'd also like to hear comments from others. |
|
* William Woodall <notifications@github.com> [2017-05-08 02:36]:
I'd have to defer to @tfoote, but my understanding is that we don't automatically add the version dependency so that non-ABI breaking changes don't require downstream packages to reinstall.
But non-ABI breaking changes shouldn't change the Soname as well ;).
Seems to me you'd have the same problem with ABI breaks and lax versioning whether or not there is a separate library package or not. Maybe I'm missing some as to how having the separate library would address this issue implicitly.
Quoting Debian policy 8.1:
| The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes. This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version. Normally, the run-time shared library and its SONAME symlink should be placed in a package named librarynamesoversion, where soversion is the version number in the SONAME of the shared library. Alternatively, if it would be confusing to directly append soversion to libraryname (if, for example, libraryname itself ends in a number), you should use libraryname-soversion instead.
It looks like this is a symptom of them (the moveit developers) using SO versioning, which changes the library name for each release. If that's the case then I think they can add `${shlibs:Depends}` to their `Depends` as a patch during the bloom release. Anything you can do in a rules file you can do and still use `bloom`.
That wouldn't change anything, read the moveit bug ;).
|
I didn't say that they did. I don't see why pointing that out should change how we build the packages which don't use so versioning. |
|
Also, putting the library into its own package only helps if your also using so versioning, which was what I didn't understand from your original post. You can modify the control file to produce multiple packages after bloom creates the basic control file. That should work ok. Or they could turn off so versioning when building on our build farm since the advantages are mostly lost due to not having multiple debs, one for each so version, which can be installed simultaneously. That way they don't have the problem of the rolling library name. Or they could figure out why the downstream packages are not linking against the symlinked so without a version in the name. I'm still ok to add this patch if it can be shown to be low risk for regressions and others think it's a good idea. |
|
* William Woodall <notifications@github.com> [2017-05-08 12:24]:
Or they could turn off so versioning when building on our build farm since the advantages are mostly lost due to not having multiple debs, one for each so version, which can be installed simultaneously. That way they don't have the problem of the rolling library name.
Given the numerous comments about the Soname change, I think it's quite
the opposite and working quite nicely :). (If breaking the ABI in a
release is a totally different question.)
Or they could figure out why the downstream packages are not linking against the symlinked so without a version in the name.
That's on purpose and the correct behaviour. Otherwise the Soname
linking wouldn't work.
|
This is the point (from the Debian guide quoted above) that I meant was not working:
If there's still benefit to having it as-is then that's fine too.
I don't understand what you mean here.
You're right, sorry I was thinking about something else. |
We do not have information on the libraries or their so-name that are being packaged, so bloom cannot automate this process. However, you can modify the control and rules files generated by bloom and add any information you like there. |
|
* William Woodall <notifications@github.com> [2017-05-08 13:27]:
> (If breaking the ABI in a release is a totally different question.)
I don't understand what you mean here.
I don't think changing the ABI in a release is a good idea, as it will
break all downstream projects (doing so explicitly by changing the
Soname is good, though). But that's a question for Moveit/OSRF.
|
I agree, and we try to avoid it on the core packages, but we do not wish to enforce that for all ROS packages. So it is up to each individual maintainer to work with their users to meet their needs with respect to ABI compatibility. I know that's not ideal, but it's a compromise to make it easier to release packages for novice maintainers until we have better tools for specify this information in a cross-platform way and a way to enforce ABI compatibility on some packages but not others. |
|
This pull request has been mentioned on ROS Discourse. There might be relevant details there: https://discourse.ros.org/t/no-version-constraints-in-package-dependencies/28677/1 |
bloom doesn't create separate library packages according to the Debian
policy naming scheme. As we allow ABI breakage in the release (see
Moveit), this results in too lax dependencies for example:
Depends: ros-kinetic-moveit-core
instead of (for example)
Depends: ros-kinetic-moveit-core (= 0.9.6)
Resulting in a library not found when the library name changes.
This adds strict dependencies for all packages containing shlibs.
More discussion: ros-planning/moveit#497