Hi,
On 20/09/2023 15:22, Markus Koschany wrote:
Hello,
Am Mittwoch, dem 20.09.2023 um 10:17 +0200 schrieb Emilio Pozuelo Monfort:
I'm unsure about the version here. I see buster/bullseye have:
libyang | 0.16.105-1+deb10u1 | oldoldstable | source
libyang | 1.0.225-1.1 | oldstable | source
So if you backported bullseye's version, there would be no need for a +really
version afaics. Usually the +really hack is used when going backwards, not
forwards. It could have just been 1.0.225-1.1~deb10u1, couldn't it?
Also I'm confused about 0.16.105+really1.0-0+deb10u1. Is it 1.0 or 1.0.225
like
in bullseye?
The version of libyang in Buster is code-wise identical to the version in
Bullseye now. The major difference is that I did not bump the ABI version to
1.0 which is usually reflected by renaming the binary packages. I did that to
avoid a delay in the NEW queue and I wanted to keep the current packaging
layout.
Hmm, so upon closer inspection, that new version ships libyang0.16 but it
contains libyang.so.1. That's bad as it defeats the purpose of versioned library
packages. For one it breaks all libyang0.16 users, whether in the archive or
outside of it. I don't think avoiding a trip through NEW should cause this.
Usually NEW is not a problem for security uploads.
Also upgrades to Bullseye still should work as expected.
That's not true, as now bullseye's libyang1 ships files that are in buster's
libyang0.16, but without proper breaks/replaces. Obviously the fix for that is
not to add breaks/replaces to libyang1's, but to fix the buster package. See
this quick test in a clean buster chroot:
apt update
apt install libyang0.16 libyang-dev
echo "deb http://deb.debian.org/debian/ bullseye main" > /etc/apt/sources.list
apt update
apt dist-upgrade
[...]
dpkg: error processing archive
/tmp/apt-dpkg-install-tQ319q/20-libyang1_1.0.225-1.1_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/libyang.so.1.10.17', which is
also in package libyang0.16 0.16.105+really1.0-0+deb10u1
The version in
Bullseye breaks against all versions of yang-tools << ${source:Version}. If the
version were 1.0.225-1.1~deb10u1 then this would not have worked anymore and
the upgrade fails.
I don't think that matters, because those breaks are in the new libyang-tools
package, which break/replace the old yang-tools package. It's a package rename,
but it comes with a transitional yang-tools package, which pulls the
libyang-tools package. Thus the upgrade should have been clean, only that a user
that had yang-tools would end up with libyang-tools plus an empty transitional
package yang-tools, just like in a buster->bullseye upgrade.
Thus +really1.0 appeared to be the logical solution for all
these problems and just indicates that the new version is part of the 1.x
branch with its new ABI. Besides frr was the only reverse-dependency, so I
could rule out a negative impact on unrelated packages.
I think the way to clean this up is to switch to the bullseye packaging and move
to 1.0.225-1.1~deb10u1. libyang1 will need to gain extra breaks/replaces for the
file conflict, and thus with this fixed in buster, the upgrade to bullseye
should be clean.
Let me know if you want me to take care of the above.
Cheers,
Emilio
