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 <[email protected]> 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 >
