Re: at-spi versioning



On Tue, 2003-04-22 at 11:13, Bill Haneman wrote:
> > Forcing soname numbers to make them artificially match some external
> > expectation of what they should be is almost always wrong.
> > 
> > Going backwards on soname versions is *alway* wrong.
> > 
> > If you released tarballs of ati-spi that had a major of 1, and have
> > since broken binary compatibility, you _must_ use a major of at
> > least 2 now.
> 
> We didn't break bincompat, but somehow a .so.1 got released *and*
> bundled with RH8.0.
> 
> You didn't directly answer the question, which is,
> "should we release .so.1.foo now, breaking lib compat, or just ignore
> the obsolete library?"
> 
> I assume you are lobbying for releasing 1.0.something now, but that will
> (otherwise needlessly) break bincompat for everything built against the
> .so.0 series.  Yuck.

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.

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:

install-local:
	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
        fi

(Untested)

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.

Regards,
                                      Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]