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


Groups > linux.debian.project > #10382

Re: Binary compatibility policy for security updates and point releases

From Jakob Leben <jakob.leben@gmail.com>
Newsgroups linux.debian.project
Subject Re: Binary compatibility policy for security updates and point releases
Date 2019-03-17 20:30 +0100
Message-ID <xCJDQ-83x-17@gated-at.bofh.it> (permalink)
References <xCvhw-50z-1@gated-at.bofh.it> <xCyfn-6Ph-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

On Sun, Mar 17, 2019 at 12:11 AM Ximin Luo <infinity0@debian.org> wrote:

>
> In general, if no documented guarantee exists then you should assume there
> is no guarantee.
>

That's what I thought too.


If you are a developer and you link against a particular version of a
> library in Debian 9.1 and its ABI changes in 9.2, it's a simple task to
> rebuild it, and in fact that is what all reverse-dependencies of that
> library in Debian would themselves have to do. Not a big deal; as a
> developer you are supposed to deal with these issues and make it
> transparent to your end users.
>
>
Well, there are use cases that are not so simple. For example: I might
deploy Debian 9.1 on an embedded machine sold to a client on the other side
of the world. I have a system for updating my own software which is also
deployed on that machine, but not the rest of the Debian system. Now, if
ABI might change between 9.2, then I have no guarantee that if I test my
software update with 9.2, it will be work as expected on the client's
machine with Debian 9.1. However, building and testing my software with
Debian 9.1 might be a problem. For example, the official Debian Docker
images (https://hub.docker.com/_/debian) are only provided for the latest
point release. Finding older point releases from other sources is also not
the simplest, and seems to be discouraged and not perfectly supported. See
for example the notes here:
https://cdimage.debian.org/mirror/cdimage/archive/

Note that this use case requires that ABI does not change at all - not even
in a backwards compatible way, because in that case I might inadvertently
start using a new symbol introduced in a library in 9.2 which is not
present on the client's 9.1 system.

For these reasons, I would appreciate if the documentation was a little
more transparent about binary (in)compatibilities across point releases and
security updates.

Best regards,

Jakob

Back to linux.debian.project | Previous | NextPrevious 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