Re: at-spi versioning

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,
>  Red Hat 9   - at-spi 1.1.9,
> 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.

- Bill

> 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 like:
> install-local:
> 	oldlibs=`echo $(libdir)/*`
>         if test $$oldlibs != "$(libdir)/*" ; then
>           echo "*** Old libspi.1.0.x library found in $(libdir)"
>           echo "*** Please remove $(libdir)/ 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
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

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