Le Tuesday 11 November 2008 10:38:48 Johannes Meixner, vous avez ?crit?:
> Hello,
>
> On Nov 8 10:06 stef wrote (shortened):
> > as a proof of concept, I have made 2 different versions of SANE
> > coexisting on my system.
>
> ...
>
> > I have created a meta backend which is a copy of dll.c,
> > but that searches only backends with a major of 1 and has no
> > preloaded backends. I added the meta backend to dll.conf.
>
> Very many thanks for this real test!
>
> Regardless what the final result will be, the only thing which
> is of real importance for us (i.e. for the openSUSE distribution)
> is that different SANE versions work o.k. out of the box.
>
> "work o.k. out of the box" means on the one hand
> no loss of supported models (i.e. no regression bugs)
> but on the other hand it menas that it can happily crash
> when the user did special manual changes.
>
> For example we use a backend only via a dll meta backend
> (and I assume the other distribution do it too - i.e.
> no backend is directly linked with a frontend) so that
> you can add as many meta-backends as you like
> as long as this works o.k. out of the box.
>
> "Out of the box" means also that it would be no problem for us,
> to provide an updated SANE 1 sane-backends package together
> with a new SANE 2 sane2-backends package if changes in the
> SANE 1 sane-backends package are required so that this one
> can coexist with the SANE 2 sane2-backends package.
> This is no problem for us because we provide the "whole box"
> i.e. we can easily provide an updated SANE 1 sane-backends
> package in the next openSUSE version if it is needed.
> This would also work for an update from one openSUSE version
> to the next openSUSE version because the installed packages
> (i.e. the installed sane-backends) would be updated too.
>
>
> If I understand you correctly, the dll meta backend
> is the one of the newest SANE version.
>
> Assume now there is SANE version 1, 2, and 3 which should
> coexist on one system:
>
> Then the dll meta backend is of version 3 which loads only
> backends which are compatible with version 3 (i.e. in its
> dll.conf there are only backends listed which are compatible
> with version 3).
>
> For backward compatibility with version 2, there is a dll2
> meta-meta backend which is compatible with version 3
> (i.e. listed in dll.conf) but this one loads only backends
> which are not compatible with version 3 but which are
> compatible with version 2 (i.e. in its dll2.conf there are
> only backends listed which are compatible with version 2).
>
> For backward compatibility with version 1, there is
> either
> a dll1 meta-meta backend which is compatible with version 3
> (i.e. listed in dll.conf) but this one loads only backends
> which are neither compatible with version 3 or version 2
> but which are compatible with version 1 (i.e. in its dll1.conf
> there are only backends which are compatible with version 1)
> or
> a dll1 meta-meta-meta backend which is compatible with version 2
> (i.e. listed in dll2.conf) but this one loads only backends
> which are not compatible with 2 but which are compatible
> with version 1 (i.e. in its dll1.conf there are only backends
> which are compatible with version 1)
>
>
> Currently I do not fully understand all implications of it
> but it seems that this naming scheme could be a drawback
> because currently the dll meta backend is of version 1.
>
> Why not keep the old name dll for the meta backend for version 1
> and use new names (i.e. dll2 and dll3) for the higher versions?
>
> Or is it better to overwrite an existing SANE version 1 dll
> by the new dll and add dll2 for backward compatibility?
>
>
> Kind Regards
> Johannes Meixner
> --
> SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
> AG Nuernberg, HRB 16746, GF: Markus Rex
Hello,
I fact I haven't touch dll.c at all. I have copied it under a new
name 'sane1.c' and did minor changes to this file to be a 'sane1' meta
backend. I have then added it to my system dll.conf which looks like:
net
genesys
lexmark
v4l
rts8891
pnm
smfp
epkowa
sane1
There is no more change than adding this compatibility meta backend.
I have currently xsane linked to libsane.so.1 and xscanimage linked to
libsane.so.2. libsane.so points to libsane.so.2. When I run xsane, it detects
pnm:0, pnm:1 and v4l:/dev/video0 . When I run xscanimage it detects these
sane1 backends as sane1:pnm:0, sane1:pnm:1 and sane1:v4l:/dev/video0 .
scanimage -L reports:
device `sane1:pnm:0' is a Noname PNM file reader virtual device
device `sane1:pnm:1' is a Noname PNM file reader virtual device
device `sane1:v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
device `v4l:/dev/video0' is a Noname USB 2.0 Camera virtual device
The SANE 2 package I installed hasn't the pnm backend enabled. The
probe log
with SANE_DEBUG_DLL and SANE_DEBUG_SANE1 set is attached. You'll notice that
it tries to load the smfp and epkowa backends. The epkowa was compiled with
SANE 2 installed on the system.
Such construct allow for SANE 2 compatible frontends to use SANE 1
backends.
If needed, by creating a similar meta backend (which would cares of the SANE
2 features to provide SANE 1 only behavior), we could allow SANE 1 compatible
frontends to use SANE 2 backends. This could be done for any new version of
SANE allowing for some complex setups.
Regards,
Stef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: probe.log.gz
Type: application/x-gzip
Size: 1026 bytes
Desc: not available
Url :
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20081111/19dfcde1/attachment.bin
