Hi Kay, > >> > The _major_ number of libudev has to be increased, because several symbols > >> > were removed (e.g. udev_device_new_from_devpath()) from the library in the > >> > changes from 128 to 129. > >> > > >> > Which means, that every application, which linked to a udev version prior to > >> > udev-129 has to be recompiled to work with newer libudev versions and > >> > unfortunately there is now no way to install compat libs anymore. > >> > >> Right, we do not bump the major number as long as it is experimental. > >> > >> It's not only the API which has changed in earlier versions, also the > >> logic behind it, so it would not really work with compat libs anyway. > >> The usual way to do compat libs by taking the code from old packages > >> will also not work, because the lib is tied to the running udev > >> version. Older libs are unlikely to work with a new udev running. > > > > you don't need to bump the package version number. Just bump the .so > > name/version of the library. > > Yeah, but we have the Debian-like lib packaging with the package name > following the lib version. The build system will not allow to have > different versions. I am not following. I was talking about this part: libudev_la_LDFLAGS = \ -version-info $(LIBUDEV_LT_CURRENT):$(LIBUDEV_LT_REVISION):$(LIBUDEV_LT_AGE) \ -export-symbols $(top_srcdir)/udev/lib/exported_symbols So you increase $(LIBUDEV_LT_CURRENT) while keeping $(LIBUDEV_LT_AGE) and resetting $(LIBUDEV_LT_REVISION). Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html