Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [hwloc-devel] hwloc in Debian, anybody working on RPMs?
From: Tony Breeds (tony_at_[hidden])
Date: 2009-11-23 21:28:45

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
> docs.

> 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.

Yours Tony