#4385 galsim v1.0.1

Added_to_Fink
closed-accepted
nobody
None
5
2014-01-30
2014-01-25
Mike Jarvis
No

This is a fairly minor update with a few bug fixes. I believe I did update the SCons stuff to correctly get the version and install_name, which were not correct for v1.0.0. This is packaged as a revision update to the fink galsim package: 1.0-2

It passes all the normal tests, and otool -L reports the correct directory and version number now:

$ otool -L /sw/lib/libgalsim.1.0.dylib
/sw/lib/libgalsim.1.0.dylib:
/sw/lib/libgalsim.1.0.dylib (compatibility version 1.0.0, current version 1.0.1)
/sw/lib/libtmv_symband.0.dylib (compatibility version 0.70.0, current version 0.71.0)
/sw/lib/libfftw3.3.dylib (compatibility version 7.0.0, current version 7.2.0)
/sw/lib/libtmv.0.dylib (compatibility version 0.70.0, current version 0.71.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 219.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

1 Attachments

Discussion

  • If the real upstream version is 1.0.1 (as noted by the Source field), what's the rationale for keeping the Fink package version at 1.0 ?

     
  • Mike Jarvis
    Mike Jarvis
    2014-01-28

    No strong rationale. There are no API or functionality changes -- just bug fixes, so I thought it would make sense to keep it as 1.0 and just change the revision, but looking at other packages, I guess that's not actually the norm in fink. So I don't mind changing it to 1.0.1.

    The only thing I don't know how to make work using Version = 1.0.1 is that the library is called libgalsim.1.0.dylib. Only 2 version levels. Is there a standard way to strip off the last digit of the version for the Shlibs field? Currently, I call it !%p/lib/libgalsim.%v.dylib, which will be wrong if %v = 1.0.1.

     
  • The software version and -install_name number (N) of a dylib do not need to match or stay in sync (for an extreme version, poppler 0.22.5 has a library called libpoppler.37.dylib). The number just indicates that the developer has declared that libraries with number N have a compatible API. The API level is generally a single digit (LIBMAJORVERSION), but that is not set in stone (only that N libraries be compatible). Calling the library libgalsim.1.0.dylib is not wrong, either for version 1.0, 1.0.1, or even 2.8 as long as the library API is stable while it is called libgalsim.1.0.dylib.

    If the library API was stable between galsim-1.0 and and galsim-1.0.1, there's no reason to change the install_name number of the library. The Shlibs: field annotation would just stay as !%p/lib/libgalsim.1.0.dylib rather than using %v.

    Note: these rules are primarily important when shared libraries are public and accessible for outside programs to link to them (because you don't want to name incompatible libraries the same thing). In this case, since libgalsim.XYZ.dylib is private, it could just be called libgalsim.dylib, or libgalsim.1.dylib or libgalsim.1.0.1.dylib, but there's no sense in playing random games with the versioning.

     
  • Mike Jarvis
    Mike Jarvis
    2014-01-30

    OK, I just hard coded the Shlibs field to use 1.0. I thought there might be some clever way to strip off the end of the %v that wasn't occurring to me to ease maintainability, but it's not so onerous to remember to edit that line when we move up a major version level. :)

    I'm attaching a new info file that calls this version 1.0.1.

     
    Attachments
    • status: open --> closed-accepted
    • Group: Undergoing_Validation --> Added_to_Fink
     
  • Added to the 10.7 tree. Thanks for the submission.

     
  • Mike Jarvis
    Mike Jarvis
    2014-01-30

    Thank you!