libudev major number not increased

libudev major number not increased

[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.

Re: libudev major number not increased

[Kay Sievers]

On Tue, Apr 14, 2009 at 15:09, Harald Hoyer <harald@redhat.com> wrote:
> 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

Re: libudev major number not increased

[Marcel Holtmann]

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.

Regards

Marcel

Re: libudev major number not increased

[Kay Sievers]

On Tue, Apr 14, 2009 at 15:47, Marcel Holtmann <marcel@holtmann.org> wrote:
>> > 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.

Kay

Re: libudev major number not increased

[Marcel Holtmann]

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

Re: libudev major number not increased

[Kay Sievers]

On Tue, Apr 14, 2009 at 17:05, Marcel Holtmann <marcel@holtmann.org> wrote:
>> > 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).

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