[Development] Removing libudev dependency from binary packages?
Thiago Macieira
thiago.macieira at intel.com
Wed Oct 23 09:25:11 CEST 2013
On quarta-feira, 23 de outubro de 2013 07:23:22, Alejandro Exojo wrote:
> Isn't exactly the same situation as with Qt? When the "next version of Qt
> 4.8" breaks binary compatibility, libqt5 is introduced. You link against
> either one or the other, and generally, both could be available for you to
> choose.
>
> I'm surprised that libudev0 is not there, though. I suppose all
> applications that used libudev0 are ported to the new one.
This is the "source version" number thing we went through with Qt 5.
A library name of type "libname.so.N" contains two versions: the source
version and the binary version. The source version indicates the source
compatibility, the binary one indicates whether there have been any binary
compatibility breaks.
A couple of very explicit examples:
libQt5Core.so.5
libgtk-x11-2.0.so.0
Though extremely unlikely for either of those big libraries to release a
version that breaks BC and keeps SC, it's possible. It's a lot more common in
smaller libraries and we've seen that throughout the years. Examples:
libdbus-1.so.2 and libdbus-1.so.3 (granted, the "1" is the protocol)
libudev.so.0 and libudev.so.1
libpng15
mysql client libraries (which also give us packaging headaches)
libc itself (libc.so.6 is source compatible with libc.so.5)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131023/f321083a/attachment.sig>
More information about the Development
mailing list