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 > > > > (0x00007fb732d54000) > > > > libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 > > > > (0x00007fb732d3c000) > > > > > > > > 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
