From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcel Holtmann <marcel@holtmann.org>
Date: Tue, 14 Apr 2009 15:05:08 +0000
Subject: Re: libudev major number not increased
Message-Id: <1239721508.11795.37.camel@violet>
List-Id: <linux-hotplug.vger.kernel.org>
References: <49E48B22.9020701@redhat.com>
In-Reply-To: <49E48B22.9020701@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-hotplug@vger.kernel.org

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