[sane-devel] Patch to make XSane work with SANE 1.1

Olaf Meeuwissen olaf.meeuwissen at avasys.jp
Tue Oct 14 23:37:30 UTC 2008

"m. allan noah" <kitno455 at gmail.com> writes:

> On Tue, Oct 14, 2008 at 6:31 AM, Julien BLACHE <jb at jblache.org> wrote:
>> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>> Hi,
>>>> 2. Release this as sane 2.0.
>>> If there were few other changes besides those for the 1.1 stuff, a
>>> soversion bump is probably the best way to move forward.  However,
>>> considering the scope of the changes, 2.0 feels a little like an
>>> overstatement and we could consider some extra, non-controversial!,
>>> API-breaking changes.  Are there any ;-)
>> Also note that the soname bears no relation to the SANE standard
>> version, and should not.
>> SANE standard version can be part of the library name, ie
>> libsane-2.so.1 would be SANE 2.0.

ACK.  I am aware of the distinction but forgot about it when replying
yesterday :-(

> while this is technically true, i personally find it kind of annoying.
> A library like sane effectively IS its interface, so changing the
> interface is changing the version number.

ACK here as well.  A libsane.so.2 for SANE 1.1 and libsane2.so.1 for
SANE 2.0 may be somewhat confusing but it's probably the only decent
thing to do.  So if we bump the soversion for SANE 1.1, then all 1.1
backends need to do so as well and an 1.1 dll backend needs to be made
to look for .so.2 backends.  IIRC, it already looks for .so.# files,
but the # is the SANE MAJOR version.

  [Me goes and checks]

Yup, it appends V_MAJOR and just about every backend (epkowa included)
confuses that with the SANE Standard defined SANE_CURRENT_MAJOR when
it creates a SANE_VERSION_CODE.  Only the snapscan backend does the
right thing here.

There is an interesting little snippet in ChangeLog-1.0.1 on February
27, 1999:

  * backend/snapscan.c (EXPECTED_MAJOR): Update EXPECTED_MAJOR to 1.

  * include/sane/sane.h (SANE_CURRENT_MAJOR): SANE_CURRENT_MAJOR and
  V_MAJOR HAVE to be in sync, so I'm forced to fix SANE_CURRENT_MAJOR
  now.  Embarassing, but fortunately only the snapscan backend seems
  affected by this change.

  * backend/dll.c (load): Use SANE_CURRENT_MAJOR, not V_MAJOR (the
  latter is used for shared lib versioning).

It looks there a fair bit of version number unconfusing to be done
before we can ship 1.1.  There's the SANE Standard, library version
information (soversion, etc) and the sane-* package versions.  Up till
now, these happened to be pretty much the same, numerically, but they
have always been independent in terms of meaning.  The numerical
similarity seems to have confused their use for the last 10 years or

FWIW, the libtool Versioning section[1] may be an interesting read.

[1] http://www.gnu.org/software/libtool/manual/libtool.html#Versioning

Hope this helps,
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom

More information about the sane-devel mailing list