Re: usbguard soname stability
On 12/08/2016 02:34 PM, Muri Nicanor wrote:
> the usbguard source package ships a shared library libusbguard0. i asked
> upstream about bumping the soname when the interface changes, but
> upstream considers usbguard 0.x as not stable yet and will start
> maintaining soname version beginninig with 1.x (which is understandable).
I know that this won't necessarily convince upstream, but the SONAME
version and the project version are two very distinct things, and
they should _not_ be changed in tandem - they should be completely
independent.
A SONAME only tracks whether the library is still binary-compatible
with programs compiled against the same SONAME. (But there is only
backwards compatibility guaranteed here, not forwards compatibility.)
For example, on my system I have in /usr/lib/<triplet> a library
libzip.so.4 (part of the libzip4 package), but the package version
is only 1.2; this just means that there have been more incompatible
changes in the library that there have been major versions.
Conversely there's libpulse.so.0 (from the package libpulse0) that
is already at version 9 - this just means that there never has been
an incompatible change in that library. (Or at least none that was
so severe that people felt like increasing the SONAME.)
So if upstream refuses to bump the SONAME even with incompatible
changes, they're doing Linux shared objects wrong. A SONAME of
.so.250 doesn't mean the software is mature (it probably means
the exact opposite, because stuff is changed so often ;-)), and
the software's actual version can still easily be 0.5 at that
point.
Now I realize that you won't necessarily be able to convince
upstream of that - unfortunately. And if you can't, I would
recommend going the route in installing the library into a sub-
directory of /usr/lib/<triplet> + setting the RPATH, so that
it's clear that this is an internal library. (Assuming that there
are no rdeps of the library in Debian. If there are rdeps in
Debian, then I don't have any good advice, because then it's a
publicly used library and really _should_ do proper SONAME
handling of it.)
> and related: because upstream does not consider the project stable yet,
> i'd file an rc bug (in the full freeze time) to prevent the package from
> transitioning to stable. or is there an better/alternative way?
Define "stable". Unusable? Insecure? If so, you should keep it out
of Stretch. But just "interfaces may change quite a bit in the
future" is not a reason to keep it out of stretch if you believe
that the software is in good shape and supportable for as long as
Stretch is supported.
Basically: if you believe either you or the security team can
backport security fixes without too many difficulties during the
lifetime of Stretch, the software should go in. If you think that
this is going to be too difficult, file a RC bug to keep it out
for now (and revisit for Buster) - and if you're unsure, talk
with upstream and the Debian security team before making a
decision. Note that you can always ask the release team for
manual removal from testing later, so as long as you don't drop
the ball on this and take until the release itself to figure this
out, I wouldn't file an RC bug right now, but first try to
determine if you think it should be in Stretch or not - and then
make an informed decision.
Hope that helps.
Regards,
Christian
Reply to: