Bug#998169: marked as done (transition: unixodbc)
Your message dated Sun, 21 Nov 2021 18:20:39 +1100
with message-id <ME3P282MB366574479035D2AE70D784D0F29E9@ME3P282MB3665.AUSP282.PROD.OUTLOOK.COM>
and subject line Re: Bug#998169: transition: unixodbc
has caused the Debian Bug report #998169,
regarding transition: unixodbc
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
998169: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998169
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: transition: unixodbc
- From: Hugh McMaster <hugh.mcmaster@outlook.com>
- Date: Sun, 31 Oct 2021 22:30:26 +1100
- Message-id: <163567982608.3036.4237979980610579838.reportbug@debian>
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
Due to various changes, unixodbc's libraries, libodbc, libodbccr and libodbccr
have a new soversion.
Test results after rebuilding all reverse dependencies and reverse-build
dependencies:
The following packages FTBFS for reasons unrelated to unixodbc:
* asterisk; see #997136
* libghc-hdbc-odbc-dev (src:hdbc-odbc); not in testing
* libmyodbc (src:myodbc); not in testing
* pike8.0-odbc (src:pike8.0); not in testing
* w1retap-odbc (src:w1retap); not in testing
tdbcodbc will require a source or NMU upload; see #997057, where the maintainer
says he will take care of this.
grass, vtk7, mysql-workbench and saga all require rebuilds once gdal is
rebuilt.
Ben file:
title = "unixodbc";
is_affected = .depends ~ "libodbc1" | .depends ~ "odbcinst1debian2" | .depends
~ "libodbc2" | .depends ~ "libodbccr2" | .depends ~ "libodbcinst2";
is_good = .depends ~ "libodbc2" | .depends ~ "libodbccr2" | .depends ~
"libodbcinst2";
is_bad = .depends ~ "libodbc1" | .depends ~ "odbcinst1debian2";
--- End Message ---
--- Begin Message ---
Hi Sebastian,
On Thu, 18 Nov 2021 at 08:21, Sebastian Ramacher wrote:
>
> We had some discussions on this transition on #debian-release some days
> ago. From what I understand (please correct me in case I misunderstood
> something): there is no ABI break involved, so this is solely a
> "transition" to clean up the packaging bits. This is not what
> transitions are for.
>
> Without ABI break, libodbc1 and odbcinst1debian2 need to stay.
>
> If you want to clean up the packaging, you can probably move
> libodbc2.so.2 to libodbc2, libodbccr.so.2 to libodbccr2, and
> libodbcinst.so.2 to libodbcinst2. libodbc1 and odbcinst1debian2 could
> then be transitional packages with the compat symlinks that stay around
> at least for bookworm. Be aware of the usual pitfalls when moving files
> between packages.
That is generally what I wanted to do, although without the older packages.
If there is no alternative, I'll restore the old packages.
> In general, I would just not touch that at all and wait for the next ABI
> break to perform the clean up. Especially if one considers the reverse
> dependencies of unixodbc. One will want mariadb-10.5 (from bullseye) and
> maridb-10.x (from bookworm) co-installed after the upgrade so that one
> can migrate all the databases. I can imagine similar issues with php-7.4
> and php-8.x. With the current state in experimental, this won't be
> possible.
Thanks for letting me know about the mariadb situation. I wasn't aware of this.
--- End Message ---
Reply to: