[sane-devel] Sane Release 1.1.0 ?

Tue Nov 4 09:36:11 UTC 2008

stef <stef.dev at free.fr> writes:

> Le Tuesday 04 November 2008 03:02:07 Olaf Meeuwissen, vous avez écrit :
>> stef <stef.dev at free.fr> writes:
>> > Le Wednesday 29 October 2008 19:59:09 Julien BLACHE, vous avez écrit :
>> >> Nicolas Martin <nicolas.martin at freesurf.fr> wrote:
>> >
>> > ...
>> >
>> >> Also calling the current CVS SANE 2.0 is really a bad joke given
>> >> there's only very little changes compared to SANE 1.0. I don't think
>> >> it's warranted and I don't think it's a good thing.
>> >>
>> >> JB.
>> >>
>> >> --
>> >> Julien BLACHE                                   <http://www.jblache.org>
>> >> <jb at jblache.org>                                  GPG KeyID 0xF5D65169
>> >
>> > 	Hello,
>> >
>> > 	there are only 2 changes in the SANE API:
>> > 	- new SANE_FRAME values
>> > 	- new SANE_STATUS
>> >
>> > 	Whenever a frontend built against SANE 1.0 receive one of the new
>> > status, it shows the error properly. Like SANE_STATUS_COVER_OPEN, JAMMED
>> > or NO_DOCS, in case of SANE_STATUS_WARMING_UP user has to correct the
>> > error condition (in this case just by waiting) before starting a new
>> > scan. When the error condition is fixed (scanner is warm enough), the
>> > scan goes normally.
>> >
>> > 	For the new frame formats (tested with a hacked pnm backend), when XSane
>> > receives a format it doesn't know, there is a 'Bad frame format 11'
>> > pop-up. Kooka doesn't send any error, and user gets a black scan .
>> >
>> > 	So the current picture of using a SANE 1.0 frontend against a SANE 'next
>> > version' is that there may be some errors in the case the user requires
>> > an frame format that isn't known for the frontend. Currently only the bh,
>> > coolscan3 and fujitsu backends take advantage of the new SANE_FRAME
>> > values.
>>
>> Any frontend using the dll backend will be affected, in principle.
>>
>> > 	If you think -as a package maintainer- these errors are important enough
>> > to require a V_MAJOR increase, we'll have to call next SANE version SANE
>> > 2.0 due to the way the standard worked (only the major is taken into
>> > account), and the way backends misused V_MAJOR instead of
>> > SANE_CURRENT_MAJOR.
>>
>> For all I know, all backends but one still misuse V_MAJOR.
>>
>> Personally, I am of the opinion that we should clean up the version
>> mess first and come up with a workable and backwardly compatible
>> versioning scheme.  Any such scheme should allow for simultaneous
>> installation of multiple (major) versions.
>
> 	The clean-up you are thinking of is going through all the sane_init function 
> in all backends and change the version code building to use 
> SANE_CURRENT_MAJOR ? 

That's only part of what I was thinking about but, yes, fixing the
abuse of V_MAJOR in the current backends is the first step.

Other things that need to be addressed are:

 - dealing with different soversions of backends that implement the
   same major version of the SANE API specification
 - decide how we want to handle minor version updates to the SANE API
   specification, if at all
 - dealing with sane-backends packages that cater to different major
   versions of the SANE API specification
 - clean upgrade paths for frontends and backends (including external
   frontends and backends)

>> > 	I am comfortable with releasing the current CVS as SANE 2.0 even the
>> > amount of API change is minimal since is has a technical merit. Keeping
>> > the current work as SANE 1.1 doesn't disturb either since the errors
>> > would be limited, but I'm not the one that will have to cope with the bug
>> > reports.
>> >
>> > 	But i definitely want a conclusion to be taken regarding how to call
>> > next version 2.0 or 1.1.
>>
>> What version are you talking about here?
>
> 	SANE current CVS which has SANE 1.1 version in code.

You seem to be talking about the package version then.  Yeay!  Yet
another number that potentially adds to the version confusion.

>> I agree with Julien that bumping the API specification version to 2.0
>> is a bad joke.  Bumping the soversion of those backends that actually
>> support/use the additions to 2 is the Right Thing to do, however.
>
> 	Feature wise, it is heavy handed to call it 2.0, but it sides step issues 
> with unmaintained backends that would have been to be changed. But also, 
> having a current major change would allow in dll.c to choose between a 
> sane1/sane2 subdir based on the major required by the frontend, providing 
> esay coexistence of both versions.

That assumes that the dll backend knows how to handle both versions.
It also needs changes in the way the dll backend locates other
backends as it currently only searches the $pkglibdir for libraries
that match libsane-*.so.$V_MAJOR and are listed in dll.conf.

# Slightly off topic, I would like to see support for recursion into
# subdirectories as that makes it easier to maintain external/vendor
# backends.

>> # Note that the current dll backend implementation does NOT support a
>> # mixed soversion scenario.
>
> 	I agree with you, fontends that follow the SANE API (such as xsane and 
> gnoescan) use only the major number to check the compatibility. libkscan 
> doesn't check anything and as then no troubles.

If libkscan doesn't check anything, then I expect nothing but trouble.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962