On Nov 23, 2009, at 9:28 PM, Tony Breeds wrote:
> > 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
> sources and (potentially) $app stops working.
Yes. But the SVN trunk will never be released as an official
version. We'll only ever release from an official SVN release branch,
and we'll set the .so version correctly right before that release.
> 0.9.2 is out there, so at some level 0.0.0 is the first public ABI,
> 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.
I guess it's just a matter of time, right? Right now, the official
released version is 0.0.0, but someday it'll be a.b.c. Given that
argument, if the trunk is x.y.z, then there exists the possibility
that someday the released a.b.c could equal (or be numerically
compatible with) x.y.z. However, if we keep the trunk at 0.0.0, then
it could only ever be numerically compatible with the 0.9.1 release
(i.e., going backwards instead of going forwards). I suppose we could
have started 0.9.1 with .so version 1.0.0 to avoid this problem, but
hindsight is 20/20.
But I think the problem is pretty minor because we'll never release
from the SVN trunk.
> > 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
> but that can be worked around :)
True. We googled around to try to find a fairly unique name before we
re-branded from libtopology (because there *was* a name collision with
that project). Hopefully it'll stay unique and/or we'll gain enough
of a following that it'll be unambiguously "claimed" for this
> anyway FWIW the SPEC file is at:
> it still needs some work, as as you say it's pretty basic.
Awesome -- thanks!
Do you want to commit that? If we keep the analog to the OMPI
project, we'd put it under contrib/dist/linux/hwloc.spec.