Re: libfoo.so.X symlink not created at build time
* Muammar El Khatib <muammarelkhatib@gmail.com> [110104 22:43]:
> Hi Bernhard,
>
> On Tue, Jan 04, 2011 at 05:36:37PM +0100, Bernhard R. Link wrote:
> > * Muammar El Khatib <muammarelkhatib@gmail.com> [110104 16:52]:
> > > I'm maintaining a library which new upstream version is creating at build time
> > > *.la, *.so (development symlink), and the library itself with the form
> > > libfoo-x.y.z.so but not their symlinks that match their SONAME (I was
> > > expecting something like libfoo.so.X).
> > Please take a look what their actual SONAME is (using readelf -d).
> Here I am pasting an example:
>
> $ readelf -d libCEGUIBase-0.7.5.so
[...]
> 0x000000000000000e (SONAME) Library soname: [libCEGUIBase-0.7.5.so]
[...]
> > While the SONAME usually is something like libfoo.so.X, it might also be
> > anything else (and the dynamic linker will that look for that file at
> > runtime). If the SONAME is not libfoo.so.X there is no need to have a
> > symlink of that name.
> >
>
> I think I have understood you. So, in this case I am showing I don't need the
> symlinks of type libfoo.so.X because the SONAME is itself the libfoo-x.y.z.so.
yes.
>
> > If you have something like libfoo-X.so there, then this is not a
> > development symlink, but the SONAME symlink. (so if any doc says
> > .so.X they mean -X.so in that case and if they say .so they mean the
> > real .so file and not the -X.so).
> >
>
> Then, I should provide in the library package _only_ the lib*-x.y.z.so files,
> and obviously the *.la and *.so development symlinks into -dev package. Please,
> correct me if I am wrong.
yes.
Also note that your soname now includes the whole 0.7.5 part, so that
this number should most likely be part of the library package *name*.
(as the -1 seem to have been before).
> Now, packages which depends on this library to build are going to fail with this
> change.
Things that build-depend on this package should most likely still be
build-able with the -dev package installed. (Unless that version changes
something else in comparison to packages already in the archive).
But it is a soname change. That is why you have to change the package
name, so that the old working library package (containing
libCEGUIBASE.so.1 from version 0.6.2) is not removed if some package
still depends on it. Packages build with the new -dev package will then
have a dependency on the new package name with 0.7.5 in it.
> It can be said that a library transition has to be done. I'll rebuild
> packages gotten by executing apt-cache rdepends, and contact maintainers.
If the API did not change, then those packages might only need an
binNMU.
Also note that as the version in the soname seems to be the whole version
of the library (at least I guess so, as it is as 0.7.5 seems quite
similar to the package upstream version of 0.6.2 in sid),
every future minor upstream release will most likely change the soname and
need a full library transition cycle (and perhaps waiting for NEW and so on).
In other words: Unless you have some LART big enough to get upstream
to switch back to stable ABIs, think twice if you want to keep
maintaining this library or if simply droping it from Debian might be
the better solution. I fear it might be everything but pleasent to deal with
this all the time.
If you keep maintaining it, I'd also suggest asking the release team for
advice (as they will have to deal with those transitions). Ideally after
squeeze release, though.
Bernhard R. Link
Reply to: