Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Sebastian Ramacher]

Hi

On 2021-11-25 13:22:12, Guillem Jover wrote:
> On Thu, 2021-11-25 at 12:26:29 +0100, [EXT] Vincent Lefevre wrote:
> > [Cc Sebastian Ramacher]
> > 
> > On 2021-11-25 21:42:48 +1100, Hugh McMaster wrote:
> > > On Thu, 25 Nov 2021 at 03:39, Vincent Lefevre wrote:
> > > >
> > > > On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> > > > > The symlinks must be kept for backwards compat. Please see #998169 for
> > > > > the context of this packaging cleanup.
> > > >
> > > > OK, thanks. #998169 gives the explanation.
> > > >
> > > > Note that I was also wondering whether these symblinks are still
> > > > actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
> > > > libodbc1 (>= 2.3.1), but
> > > >
> > > > $ ldd /usr/lib/libgdal.so.29 | grep libodbc
> > > > libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
> > > > (0x7fb732d54000)
> > > > libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
> > > > (0x7fb732d3c000)
> > > >
> > > > So the .so.2 names are already used, and the symlinks are not needed
> > > > for libgdal29. Now, what about the other packages? Since these .so.2
> > > > sonames were added in 2013 (8 years ago!), I suppose that the old
> > > > .so.1 sonames are no longer used at all, so that no backward compat
> > > > symlinks are needed.
> > > 
> > > I've inspected a quarter of unixodbc's reverse dependencies so far and
> > > found all were using soversion 2.
> > > 
> > > As indicated in #998169, I had removed the symlinks but was advised to
> > > reinstate them.
> > 
> > If you mean Sebastian Ramacher's message
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169#39
> > 
> > saying "libodbc1 and odbcinst1debian2 could then be transitional
> > packages with the compat symlinks that stay around at least for
> > bookworm." I suppose that Sebastian did not know that the .so.2
> > sonames were already used for some time (I recall that the change
> > in unixodbc was done in 2013). Was anything particular said on
> > #debian-release?
> > 
> > So I assume that only a transitional dummy package (without the
> > symlinks) is needed.
> 
> If we have to ship a transitional package anyway, I'm not sure why
> is there this pushback about shipping a couple of symlinks with it?
> The package will soon enough fade away.
> 
> (I mean if that implied we can solve this with just versioned
> Provides, I could understand but…)
> 
> > > I highly doubt that any package is linking via hard-coding to the
> > > old soname version.
> > 
> > Well, I think that the only potential issue is for old packages that
> > were built before the soname change in 2013 and were removed from
> > Debian at that time (thus are no longer rebuilt). But in practice,
> > compat symlinks are not kept that long, are they?
> 
> Or old locally built packages, or old third-party packages.
> 
> > Note that given the fact that libodbc1 depends on libltdl7 (>= 2.4.6),
> > which appeared in 2016, such packages from 2013 or earlier should
> > already be broken.
> 
> This would still break the "contract" of the package that potential
> reverse dependencies expect. I think there's a difference between say
> program symlinks and library symlinks, as the latter are the entire
> raison d'être of these package anyway. More so, when as per above, we
> need to ship the package in any case. :)

Indeed. These symlinks need to stay for satisfy the "contract"
of libodbc1. In bullseye, this currently is:

* libodbc.so.2
* libodbccr.so.2
* libodbc.so.1
* libodbccr.so.1

After upgrading to the bookworm version of libodbc1, the same SONAMEs
need to be provided. If the plan is to go ahead with the package clean
up, this means that libodbc1 needs to have a dependency on libodbc2 and
libodcbccr2 and it also needs provides the compat symlinks for
libodbc.so.1 and libodbccr.so.1. The same is also true for all the other
library packages that are being clean up.

What we can do after that was implemented, is to rebuild all packages in
bookworm to gain dependencies on libodbc2 and libodbccr2. Once this was
done and bookworm was released, one can think of dropping libodbc1 for
trixie.

Long story short: due to the non-transition in 2013, libodcb1 needs to
satisfy its promise to provide both the .1 and .2 versions.

Cheers
-- 
Sebastian Ramacher

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

[Cc Sebastian Ramacher]

On 2021-11-25 21:42:48 +1100, Hugh McMaster wrote:
> On Thu, 25 Nov 2021 at 03:39, Vincent Lefevre wrote:
> >
> > On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> > > The symlinks must be kept for backwards compat. Please see #998169 for
> > > the context of this packaging cleanup.
> >
> > OK, thanks. #998169 gives the explanation.
> >
> > Note that I was also wondering whether these symblinks are still
> > actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
> > libodbc1 (>= 2.3.1), but
> >
> > $ ldd /usr/lib/libgdal.so.29 | grep libodbc
> > libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
> > (0x7fb732d54000)
> > libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
> > (0x7fb732d3c000)
> >
> > So the .so.2 names are already used, and the symlinks are not needed
> > for libgdal29. Now, what about the other packages? Since these .so.2
> > sonames were added in 2013 (8 years ago!), I suppose that the old
> > .so.1 sonames are no longer used at all, so that no backward compat
> > symlinks are needed.
> 
> I've inspected a quarter of unixodbc's reverse dependencies so far and
> found all were using soversion 2.
> 
> As indicated in #998169, I had removed the symlinks but was advised to
> reinstate them.

If you mean Sebastian Ramacher's message

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169#39

saying "libodbc1 and odbcinst1debian2 could then be transitional
packages with the compat symlinks that stay around at least for
bookworm." I suppose that Sebastian did not know that the .so.2
sonames were already used for some time (I recall that the change
in unixodbc was done in 2013). Was anything particular said on
#debian-release?

So I assume that only a transitional dummy package (without the
symlinks) is needed.

> I highly doubt that any package is linking via hard-coding to the
> old soname version.

Well, I think that the only potential issue is for old packages that
were built before the soname change in 2013 and were removed from
Debian at that time (thus are no longer rebuilt). But in practice,
compat symlinks are not kept that long, are they?

Note that given the fact that libodbc1 depends on libltdl7 (>= 2.4.6),
which appeared in 2016, such packages from 2013 or earlier should
already be broken.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> The symlinks must be kept for backwards compat. Please see #998169 for
> the context of this packaging cleanup.

OK, thanks. #998169 gives the explanation.

Note that I was also wondering whether these symblinks are still
actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
libodbc1 (>= 2.3.1), but

$ ldd /usr/lib/libgdal.so.29 | grep libodbc
libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
(0x7fb732d54000)
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
(0x7fb732d3c000)

So the .so.2 names are already used, and the symlinks are not needed
for libgdal29. Now, what about the other packages? Since these .so.2
sonames were added in 2013 (8 years ago!), I suppose that the old
.so.1 sonames are no longer used at all, so that no backward compat
symlinks are needed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-24 15:16:12 +0100, Vincent Lefevre wrote:
> On 2021-11-23 17:55:54 +0100, Guillem Jover wrote:
> > Nice cleanup with the odbc packaging! Unfortunately the new
> > transitional package looks a bit broken. It contains a dangling
> > symlink:
> > 
> >   $ ls -la /usr/lib/x86_64-linux-gnu/libodbccr.so.1
> >   ls: cannot access '/usr/lib/x86_64-linux-gnu/libodbccr.so.1': No such 
> > file or directory
> > 
> > Which whould point to libodbccr.so.2. But then the package is also
> > missing a dependency on libodbccr2.
> 
> I'm wondering. Why was the soname incremented? This should normally
> not be done unless the ABI is backward-incompatible. But in such a
> case, providing a symlink is wrong and could break applications that
> expect the old ABI.

This actually also applies to the stable/testing version 2.3.6-0.1+b1,
which provides:

lrwxrwxrwx 1 14 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.1 -> libodbccr.so.2
lrwxrwxrwx 1 18 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.2 -> libodbccr.so.2.0.0
-rw-r--r-- 1  47016 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.2.0.0
lrwxrwxrwx 1 12 2019-07-21 19:09:45 /usr/lib/x86_64-linux-gnu/libodbc.so.1 
-> libodbc.so.2
lrwxrwxrwx 1 16 2019-07-21 19:09:45 /usr/lib/x86_64-linux-gnu/libodbc.so.2 
-> libodbc.so.2.0.0
-rw-r--r-- 1 447408 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbc.so.2.0.0

If the potentially buggy *.so.1 library versions are no longer used,
the corresponding symlinks could simply be dropped, and the package
split is not needed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-23 17:55:54 +0100, Guillem Jover wrote:
> Nice cleanup with the odbc packaging! Unfortunately the new
> transitional package looks a bit broken. It contains a dangling
> symlink:
> 
>   $ ls -la /usr/lib/x86_64-linux-gnu/libodbccr.so.1
>   ls: cannot access '/usr/lib/x86_64-linux-gnu/libodbccr.so.1': No such file 
> or directory
> 
> Which whould point to libodbccr.so.2. But then the package is also
> missing a dependency on libodbccr2.

I'm wondering. Why was the soname incremented? This should normally
not be done unless the ABI is backward-incompatible. But in such a
case, providing a symlink is wrong and could break applications that
expect the old ABI.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)