On Wed, Apr 15, 2009 at 10:34:56AM -0500, Peter O'Gorman wrote:
> Jack Howarth wrote:
>
> > ...I assume it is safe to bump the compatibility level in the
> > gmp and ppl info files. Unless I am mistaken this issue is also
> > exactly why the fftw3 package was left at 3.1.2 for so long
> > since the current 3.2.1 package bumps the compatibility
> > level but not the soversion. My previous understanding was
> > that the compatibility level should always be one more than
> > the major soversion. However it would appear that this doesn't
> > have to be the case and that the relationship between the two
> > is more flexible than that. If this is really the case, this
> > information should be clearly stated in the shared libraries
> > section of the fink packaging wiki.
>
> Jack,
> I don't know what the issue is with fftw3, but here is some quick info
> on install_names (sonames) and compatibility versions.
>
> For libtool built libraries the upstream developer will usually specify
> CURRENT:REVISION:AGE, and the library name on darwin is calculated as:
>
> libname.(CURRENT -AGE).dylib
>
> The compatibility version is calculated as:
>
> CURRENT + 1
>
> I dislike that +1, but it can not be removed now without breaking
> everything.
>
> This means that for your ppl example:
> # 0.10 7:0:0
> # 0.10.1 8:0:1
>
> version 0.10 of ppl had:
> libppl.7.dylib compatibility version 8.0.0
>
> version 0.10.1 has:
> libppl.7.dylib compatibility version 9.0.0
>
> So anything that uses libppl that was built using version 0.10 will
> continue to run fine using 0.10.1. *However* anything that was built
> with version 0.10.1 will *not* work if dyld sees that 0.10 is installed.
>
> This is fine if you are building your own stuff, as it is unlikely that
> you will ever downgrade your library, for a package management system
> that distributes binaries, it is quite important though. The package
> maintainer of a package that uses, in this case, ppl, must ensure that,
> when the user installs a gcc that was built with a newer ppl, the user
> also gets a newer ppl, if the dependencies only require ppl >= 0.10,
> then the user could try to run gcc and get a "crash" because dyld will
> refuse to load the older ppl.
>
> The shlibs field etc. was invented for a feature that has been on the
> list of things todo for fink for a very long time - automatically set
> depends in the binary package for the shared libraries that are actually
> used at link time. I think Justin worked on this for a while, but it was
> years ago, and I don't remember how far he got.
>
> Does this make it any clearer? Please feel free to add anything you find
> useful in this mail to the wiki.
>
> Peter
> --
> Peter O'Gorman
> http://pogma.com
Peter,
So it is completely legal in fink to go ahead and upgrade a package
(gmp-4.3.0, ppl-0.10.1 and fftw3-2.3.1) which has bumped the
compatibility level but not the major soversion number as long
as you insure that all packages that BuildDepend/Depend against these
have been updated to require the newer version? My recollection is
that there was a concern that this was a mistake upstream and that the
major soversion should have been bumped so that the fftw3 maintainer never
wanted to update to the newer version for that reason.
Regarding the additional functionality in fink, are you referring
to the missing library dependencies in dpkg (where a deb knows explicitly
all of the specific libraries that its shared libraries and executables
are linked against) such that attempting to remove a package that has
shared libraries that some other packages files need will flag an error
(no matter if the dependencies aren't stated in the info file)? My understanding
was that was extremely difficult to implement on darwin because of the
explicit path information (rpath?) used in linking.
Jack
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
