Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #10384

Re: Binary compatibility policy for security updates and point releases

Show all headers | View raw

>>>>> "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

Back to linux.debian.project | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Binary compatibility policy for security updates and point releases Jakob Leben <jakob.leben@gmail.com> - 2019-03-17 05:10 +0100
  Re: Binary compatibility policy for security updates and point  releases Ximin Luo <infinity0@debian.org> - 2019-03-17 08:20 +0100
    Re: Binary compatibility policy for security updates and point releases Ondřej Surý <ondrej@sury.org> - 2019-03-17 08:50 +0100
      Re: Binary compatibility policy for security updates and point  releases Gilles Filippini <pini@debian.org> - 2019-03-19 23:00 +0100
        Re: Binary compatibility policy for security updates and point  releases Bastian Blank <waldi@debian.org> - 2019-03-19 23:30 +0100
    Re: Binary compatibility policy for security updates and point releases Jakob Leben <jakob.leben@gmail.com> - 2019-03-17 20:30 +0100
      Re: Binary compatibility policy for security updates and point  releases Ximin Luo <infinity0@debian.org> - 2019-03-17 21:00 +0100
        Re: Binary compatibility policy for security updates and point  releases Ximin Luo <infinity0@debian.org> - 2019-03-17 22:00 +0100
      Re: Binary compatibility policy for security updates and point releases Sam Hartman <hartmans@debian.org> - 2019-03-17 21:30 +0100
      Re: Binary compatibility policy for security updates and point releases Florian Weimer <fw@deneb.enyo.de> - 2019-03-19 18:50 +0100

csiph-web