[Pkg-gtkpod-devel] libplist/libimobiledevice releases

[Boyuan Yang]

Hi all,

在 2025-07-01二的 09:59 +0200，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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-gtkpod-devel/attachments/20250701/4df75711/attachment.sig>