Re: at-spi versioning
- From: Bill Haneman <bill haneman sun com>
- To: Owen Taylor <otaylor redhat com>
- Cc: desktop-devel-list gnome org
- Subject: Re: at-spi versioning
- Date: 23 Apr 2003 11:17:32 +0100
On Tue, 2003-04-22 at 16:41, Owen Taylor wrote:
> OK, I didn't quite catch the question. So, the problem is that
> you accidentally had some release with sonames of 1.0.x surrounded
> by other release with sonames of 0.x.y?
> Looking at Red Hat releases I see:
> Red Hat 8.0 - at-spi 1.0.1, libspi.so.1.0.0
> Red Hat 9 - at-spi 1.1.9, libspi.so.0.8.0
> Not good :-), but then again, at-spi isn't a platform library
> for Red Hat so it isn't a big deal for us either way.
> For people upgrading through RPM's, the old .so.1.0.0 will
> be removed, so everything will work fine.
What about dependency management via RPMs? i.e. if someone is
installing a gnopernicus RPM, is the RPM dependency scheme smart enough
to check for at-spi version numbers rather than .soname ?
thanks for the suggestions. I'll try to pick one this week to sort this
out, I hope, once and for all.
> I think the only thing you have to worry about is the case where
> someone does a source install with --prefix=/usr over the
> top of their old install.
> My opinion is that if most of your releases have been so.0, you
> should stick with that; what you can do to catch the broken
> case is do something in your Makefile.am like:
> oldlibs=`echo $(libdir)/libspi.so.1.0.*`
> if test $$oldlibs != "$(libdir)/libspi.so.1.0.*" ; then
> echo "*** Old libspi.1.0.x library found in $(libdir)"
> echo "*** Please remove $(libdir)/libspi.so.1 and $$oldlibs"
> echo "*** And rerun make install"
> exit 1
> You could argue the other way ... that by simply bumping the
> soname to 1 you get rid of this problem, you don't have to worry
> about it, your user's don't have to worry about it. I don't think
> there is a "right" answer here.
> desktop-devel-list mailing list
> desktop-devel-list gnome org
] [Thread Prev