[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Binary compatibility and Debian updates



Hi Osamu,

Thank you for your response.

In the documents that you linked, I can only find information about the requirement that backwards-incompatible ABI changes require changing the SONAME of a library. However, I have not found explicit information stating that security updates and Debian point releases do not allow libraries to change their SONAME (and hence introduce backwards incompatible changes).

Moreover, the scenario I described requires that there be no ABI changes at all (not just backwards incompatible ones): if a Debian point release introduces a new symbol in a library, I may inadvertently link to that symbol, even though my client's embedded machine with an older point release does not have that symbol.

If you could please point me to an exact location in the Debian documentation that says that no ABI changes are allowed between Debian point releases and in security updates, that would be great. If not, I would encourage you to expand documentation to explicitly state so.

Best regards,

Jakob

On Sat, Mar 16, 2019 at 9:15 AM Osamu Aoki <osamu@debian.org> wrote:
Hi,

On Mon, Mar 11, 2019 at 10:36:10PM -0700, Jakob Leben wrote:
> Hello,
>
> I have not been able to find clear information about Debian policies for binary
> compatibility between point releases and security updates. In essence, I would
> like to know whether the binary interface of dynamic ELF libraries is
> guaranteed to remain unmodified across such updates.
>
> The reason I would like this kind of binary compatibility is that it seems a
> particular Debian point release might be available only for a relatively short
> time. For example, the official Debian Docker images (https://hub.docker.com/_/
> debian) are only provided for the latest point release, and a point release
> image may get security updates without changing the tag name. Finding older
> point releases from other sources is also not easy, and seems to be discouraged
> and not perfectly supported. See for example the notes here: https://
> cdimage.debian.org/mirror/cdimage/archive/
>
> If such binary compatibility is not ensured, the unavailability of older point
> releases makes it difficult to keep building versions of my own software
> against a fixed Debian version installed on a client's embedded machine.
>
> Therefore, I would like to see an improved documentation on the Debian policy
> and practice regarding binary compatibility.

You know a lot about binary compatibility ;-)

Yes we care too.  The beauty of Debian package management and release
management is all about maintaining binary compatibility.

Relax and learn how we do it through our documentation listed at:

  https://www.debian.org/doc/

  https://www.debian.org/doc/debian-policy/
  https://www.debian.org/doc/manuals/developers-reference/index.en.html
  https://www.debian.org/doc/manuals/debian-reference/index.en.html

Cheers

Osamu

Reply to: