[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