[Pkg-gtkpod-devel] libplist/libimobiledevice releases

[Nikias Bassen]

Hi,

thanks for your feedback. So that’s my point. I am talking about a situation where we would see a rename of all the libs of this project
(libplist, libimobiledevice-glue, libusbmuxd, libimobiledevice, libirecovery, libideviceactivation) because of the planned changes.
All libs and the related tools (e.g. idevicerestore, ideviceinstaller) would then be released at the same time with the name change.
And because we do have a name change anyway (e.g. libplist-2.0.* -> libplist-3.0.* libimobiledevice-1.0.* -> libimobiledevice-2.0.*)
I was thinking of removing the API suffix. This way, whenever we will see another major version bump, we would not
have to go from e.g. libplist-3.0.*.so to libplist-4.0.*.so but rather only bump the soversions properly.
Does that make sense?

Regards,
Nikias

> Am 02.07.2025 um 01:05 schrieb Boyuan Yang <byang at debian.org>:
> 
> Hi all,
> 
> 在 2025-07-01二的 09:59 +0200，nikias.bassen at gmail.com <mailto:nikias.bassen at gmail.com>写道：
>> Thanks for your reply.
>> 
>>> Am 01.07.2025 um 09:06 schrieb Yves-Alexis Perez <corsac at debian.org>:
>>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>> 
>>>> On Mon, 2025-06-30 at 11:36 +0200, Nikias Bassen wrote:
>>>> I wanted to ask you about some changes I have in my mind for upcoming
>>>> releases of libplist/libusbmuxd/libimobiledevice etc.
>>> 
>>> Hi Nikias, thanks for reaching out. I'm adding the maintainers list on
>>> recipients so they can chime in if needed.
>>> 
>>>> Now as you remember a few years ago, based on Martin's suggestion, we
>>>> changed the actual library name to libplist-2.0, libusbmuxd-2.0,
>>>> libimobiledevice-1.0 etc.
>>>> both the actual name and also the pkg-config name. Now I received quite some
>>>> negative feedback back then, breaking builds etc.
>>> 
>>> I can understand the negative feedback at the time of the break, but as far as
>>> I remember it was really needed to do that breakage once and then be aligned
>>> with best practice in managing shared libraries, wrt. API, SONAME/SOVERSION
>>> etc.
>>> 
>>> At least for Debian I think we're pretty happy with the current situation,
>>> except maybe the fact that releases happen pretty rarely (and thus we might
>>> have to backport fixes or package snapshot from time to time).
>> 
>> I am planning to do more frequent releases.
>> 
>>>> I have some larger changes coming up, mostly it’s about changes related to
>>>> what was summarized in this
>>>> ticket: https://github.com/libimobiledevice/libimobiledevice/issues/1672
>>>> Now I will obviously have to bump major version numbers for the libs, and at
>>>> the same time I was thinking of dropping the version suffix on the library
>>>> name again.
>>> 
>>> So you would like to rename the library so the .so would switch from
>>> libimobiledevice-1.0.so.6.0.0 to (say) libimobiledevice.so.7.0.0 or something
>>> like that?
>> 
>> That was the idea. If we keep the API version suffix, an upcoming (ABI/API breaking) release of libplist would become libplist-3.0.so.x.y.z (currently libplist-2.0.*),
>> libimobiledevice-2.0.* and obviously also a  corresponding change in the soversion.
>> 
>>> 
>>>> Several distributions have been placing symlinks for pkgconfg and/or library
>>>> names for quite some time anyway.
>>>> What do you think about this change, would you appreciate it or would you
>>>> rather be totally against it?
>>> 
>>> At first sight I don't think it'd be a good idea, both because of the new
>>> breakage/transition and because that reverts to previous name (we switch in
>>> 2020 so it's not that long, especially in Debian terms :)
>> 
>> Yes, my concern was that too, hence I reached out.
>> 
>>> But I'd be interested in opinion from other people from the team here :)
> 
> I made some maintenance in Debian in the past few years to reach a relatively
> satisfactory condition in Debian (and thus Ubuntu) for libplist/libimobiledevice
> related packages. I would say that I am fine with renaming back, if that is good
> for upstream in the long run. Not doing the renaming is also ok. The Debian
> side can handle either decision.
> 
> (My only suggestion is that the renaming for related packages should
> be coordinated together with proper dependencies, so that the distro-side
> renaming can be handled all at once.)
> 
> Thanks,
> Boyuan Yang
> 
>>> Regards,
>>> - --
>>> Yves-Alexis
>>> -----BEGIN PGP SIGNATURE-----
>>> 
>>> iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmhjiQEACgkQ3rYcyPpX
>>> RFvyUQf+KDA2G83YedAUDUPxH3XpTitMtGptV51xlRUfrpuFaHj8LyGEgoyW2mTY
>>> W0JtfTOOZlABfDMbhHHES+ZfqJsz88hTGO+D9q/tnFBCkqymh6RBCgNvfVVmGvgY
>>> k/IeAaileyy7M6pDIkUDKhNbh9/jBsvPsmd/SOH2EuUOCQr3I3rKd7evY/FlrnhS
>>> MGLXPjG0se/no6KRAWjUH/X8bAEGbMPgnni+h7DEXsf1Ig6vI83+qZ/lLW0vSP5c
>>> fvpIe7RiPHVRNK1N/ySmINEb7y/+KCGclQSJkzL21iqIFjq/Ot0qZazrTs4Vjfco
>>> uXU4gCrm63/KrZfdaCVBWSUUZo/HGw==
>>> =tZni
>>> -----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-gtkpod-devel/attachments/20250702/d1271d90/attachment-0001.htm>