Re: Binary compatibility policy for security updates and point releases
>>>>> "Jakob" == Jakob Leben <jakob.leben@gmail.com> writes:
Jakob> Well, there are use cases that are not so simple. For
Jakob> example: I might deploy Debian 9.1 on an embedded machine
Jakob> sold to a client on the other side of the world. I have a
Jakob> system for updating my own software which is also deployed on
Jakob> that machine, but not the rest of the Debian system. Now, if
Jakob> ABI might change between 9.2, then I have no guarantee that
Jakob> if I test my software update with 9.2, it will be work as
Jakob> expected on the client's machine with Debian 9.1. However,
Jakob> building and testing my software with Debian 9.1 might be a
Jakob> problem. For example, the official Debian Docker images
Jakob> (https://hub.docker.com/_/debian) are only provided for the
Jakob> latest point release. Finding older point releases from other
Jakob> sources is also not the simplest, and seems to be discouraged
Jakob> and not perfectly supported. See for example the notes here:
Jakob> https://cdimage.debian.org/mirror/cdimage/archive/ Note that
Jakob> this use case requires that ABI does not change at all - not
Jakob> even in a backwards compatible way, because in that case I
Jakob> might inadvertently start using a new symbol introduced in a
Jakob> library in 9.2 which is not present on the client's 9.1
Jakob> system. For these reasons, I would appreciate if the
Jakob> documentation was a little more transparent about binary
Jakob> (in)compatibilities across point releases and security
Jakob> updates.
I think the best you're going to get is that we're aware of the issue
and that we try and make ABIs backward compatible (although not frozen)
between point releases.
Some other factors like minimizing changes overall between point
releases tend to make ABIs fairly stable (no new symbols), but I'm aware
of cases where new symbols have been introduced to fix important bugs or
security issues.
However, there are cases where we've broken ABI compatibility within a
stable release. Haskell is one of the more obvious cases: simply
rebuilding a dependency can break the ABI of a Haskell library.
If you distribute your software as Debian packages, then you can express
your requirements as dependencies and at least know whether the customer
has a new enough point release (and even handle knowing whether you have
the right Haskell dependencies).
If not, in practice things will work fairly well, but you are correct
that there are corner cases that can be problematic.
We certainly are awary of the issue, but it is something that needs to
be balanced against other tradeoffs.
--Sam
Reply to: