libudev major number not increased
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.
Quoted 7 lines · Harald Hoyer
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.
Kay
Hi Kay,
Quoted 8 lines
Quoted 7 lines
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.
Quoted 7 lines
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.
Regards
Marcel
Quoted 10 lines · Marcel Holtmann
Quoted 10 lines
Quoted 7 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Kay
Hi Kay,
Quoted 16 lines
Quoted 16 lines
Quoted 15 lines
Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
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
Quoted 7 lines · Marcel Holtmann
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
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_symbolsSo you increase $(LIBUDEV_LT_CURRENT) while keeping $(LIBUDEV_LT_AGE) and resetting $(LIBUDEV_LT_REVISION).
But that will create a version 1 lib, and I would need to do a libudev1.rpm out of it. Or what do yo mean with "package version"?
Thanks,
Kay