On Fri, Nov 20, 2009 at 02:54:35PM -0600, Jeff Squyres wrote:
> No, we *definitely* do not want the .so version to match the hwloc
> version. See the guidance on .so version numbers in the GNU Libtool
> Note that hwloc's .so version number is controlled by the top-level
> VERSION file. There's a few comments in that file explaining the
> deal. It's meant to be changed manually as part of the release
> process. It will always be 0.0.0 on the SVN trunk; it will only be
> non-zero on the release branches.
really? Couldn't this lead to a sutuation where $app is compiled agaist 0.9.2
(with the .so version 0.0.0), time passes, the admin then builds the svn
sources and (potentially) $app stops working.
0.9.2 is out there, so at some level 0.0.0 is the first public ABI, shouldn't
the svn version either follow the some rules as release branches or be given a
version (say 99.0.0) that will not match any released version.
> My $0.02: .so.0.0.0 is ok for v0.9.2. All future releases need to
> consider whether to change the value according to the rules
> described in the Libtool docs. For example:
> I do most of that work -- some people have found the SRPM handy.
> Note that it is nowhere close to the specfiles used by
> RH/Centos/Fedora or Suse -- it is much more feature-full than what
> they use. I do believe that Fedora has good docs on their
> guidelines for their specfiles; I am not up-to-date on them, though.
> Hypothetically, the specfile should be pretty simple since we
> conform to most of the GNU standards.
Yeah the only place we (possibly) run into problems is with packages names.
but that can be worked around :)
anyway FWIW the SPEC file is at:
it still needs some work, as as you say it's pretty basic.