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. Also upgrades to Bullseye still should work as expected. 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. 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.
Regards,
Markus
Attachment:
signature.asc
Description: This is a digitally signed message part