Binary compatibility and Debian updates

[Jakob Leben]

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.

Jakob

[Osamu Aoki]

Hi,

Post by Jakob Leben
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

[Jakob Leben]

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

Post by Jakob Leben
Hi,

Post by Jakob Leben
Hello,
I have not been able to find clear information about Debian policies for

binary

Post by Jakob Leben
compatibility between point releases and security updates. In essence, I

would

Post by Jakob Leben
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

Post by Jakob Leben
particular Debian point release might be available only for a relatively

short

Post by Jakob Leben
time. For example, the official Debian Docker images (

https://hub.docker.com/_/

Post by Jakob Leben
debian) are only provided for the latest point release, and a point

release

Post by Jakob Leben
image may get security updates without changing the tag name. Finding

older

Post by Jakob Leben
point releases from other sources is also not easy, and seems to be

discouraged

Post by Jakob Leben
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

Post by Jakob Leben
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

Post by Jakob Leben
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.
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

[Osamu Aoki]

Hi,

Post by Jakob Leben
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).

I don't think you read every details of all the documentation and you
want quick answer ...

Post by Jakob Leben
  https://www.debian.org/doc/

You need to learn how to get information by yourself

Check google with keywords like
"debian testing library transition"
"debian security update policy"

Post by Jakob Leben
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.

Yah ...

[Jakob Leben]

Hi Osamu,

Post by Osamu Aoki
I don't think you read every details of all the documentation and you
want quick answer ...

Post by Osamu Aoki
https://www.debian.org/doc/

I don't think I should be reading every detail of all the documentation to
get the answer to the simple quesiton I posed. My argument is precisely
that this is such an important question that one should be able to find it
without spending days digging through all the Debian documentation.

Post by Osamu Aoki
You need to learn how to get information by yourself

You need to learn to be less arrogant.

Post by Osamu Aoki
Check google with keywords like
"debian testing library transition"
"debian security update policy"

I had checked google aplenty before you suggested it. I would expect an
answer to my question by Googling something like "Debian ABI change
policy". I did Google this phrase, and every possible phrase I could think
of, and couldn't find a clear answer.

The first phrase you suggested gives as the first result this page:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions
This page indeed suggests that an ABI change requires submitting a package
to the Debian experimental repository, which implies the change wouldn't
make it into a Debian minor version bump or a security update. However,
this page seems to be aimed at developers and not users. I would argue that
my question applies to users too (users like me, for example). Moreover,
one could hardly argue that "library transition" is a phrase that would
immediately come to the mind of a user who is interested in "ABI changes".

The second phrase you suggested does not show any results on the first page
that are related to ABI changes (at least here on my end).

Anyway, I hope someone else will contribute to this conversation, because
it doesn't look like you are hearing what I'm saying.

Best regards,

Jakob

[Joost van Baal-Ilić]

Hi Jakob,

Post by Jakob Leben
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.

<snip>

At https://www.debian.org/security/faq#oldversion it says:

"never change the Application Program Interface (API) or Application Binary
Interface (ABI)"

and

"In some cases it is not possible to backport a security fix, for example when
large amounts of source code need to be modified or rewritten. If that happens
it might be necessary to move to a new upstream version"

I guess it boils down to: Debian aims at keeping binary compatibility during
the support window of stable releases, but cannot guarantee it. Some upstreams
lack resources to help us maintaining that. Debian cannot guarantee anything:
we are a volunteer project. Otoh, I feel we have a pretty good track record;
it won't be easy to find another project doing better in this regard.

HTH, Bye,

Joost