libposix versioning

[Bruno Haible]

Hi Gary, Bruce,

In <http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00279.html>
you proposed to use libtool version 0:0:0 for libposix. But there is a
problem with that, or with using "small" increments of this version number.

A user will want to be able to build a newer version of libposix on the
same machine, install it, and all the programs linked with the previous
libposix should continue to run fine.

For the "continue to run fine" part, it is necessary that if an older
installation defines a symbol 'rpl_foo', the newer installation defines
'rpl_foo' as well. Currently it does not do so, because of two situations:

  1) The user may have applied minor updates of the OS, that fix some
     problems that gnulib worked around. For example, gnulib has workarounds
     for dup2(), fchownat(), futimens(), nanosleep(), utimensat() for
     specific Linux versions. Similarly, I've seen gnulib tests report
         "checking for working foo... no" on unpatched Solaris 10,
     but "checking for working foo... no" on a Solaris 10 with patches.

  2) We might remove some workarounds from gnulib, thinking that don't
     affect recent systems any more. (We sometimes do this for Cygwin,
     on the premise that Cygwin users update at least once every 2 years.)

In both situations, the older installation will provide a workaround
for foo(), defining rpl_foo, and the newer installation won't.

How do you intend to solve this problem?

  a) Always assign a new major version number to a new build of libposix.

  b) Add an rpl_foo symbol that merely redirects to the system's foo function
     if there is a chance for situation 1 or 2 to happen.

  c) Other ideas?

Bruno