[sane-devel] making scanbd work OOTB in debian - question about supported backends

[Louis Lagendijk]

On Wed, 2015-03-04 at 16:12 +0800, Rolf Leggewie wrote:
> On 04.03.2015 13:46, Wilhelm wrote:
> >>> What should be the effect of this env-variable SANE_BACKEND_CONFIG_DIR?
> 
> >> As maintainer, I currently need to copy all backend files from
> >> /etc/sane.d/*.conf to /etc/scanbd.  That is messy to say the least.  If
> >> SANE_BACKEND_CONFIG_DIR was a variable separate from SANE_CONFIG_DIR
> >> that wouldn't be necessary with obvious benefits to everyone.
> > 
> > All SANE desktop applications use SANE_CONFIG_DIR. scanbd must use saned
> > with a different dll.conf and therefore sets SANE_CONFIG_DIR before
> > invoking saned. SANElib looks for that dll.conf and config-files in
> > there and dll.d. The point is, that you can't direct SANE to another
> > dll.conf. And I don't see what the help of SANE_BACKEND_CONFIG_DIR could
> > be in this respect.
> > 
> > But: is SANE_BACKEND_CONFIG_DIR a SANElib env-variable? Don't know about it.
> 
> I am coming purely from a package maintainer's POV.  I haven't looked
> deeply into the interaction between scanbd and saned.  And I know very
> little about the limitations imposed on that interaction by the design
> of saned.  It seems that me looking for a way to split the general
> scanbd configuration from the location of the backends can only be done
> if saned supports that and then indeed your suggestion of the -c and -d
> parameters is probably the way to go.
Scanbd does not really need a separate config dir, if we could convince
saned to use a different dll.conf. I once had a look at implementing
this (add an environment variable SANE_DLL_CONF) that overrides the
default dll.conf. It turned out this required more complicated changes
to dll.c because of the dll.d directory being read as well (see dll.c
line. To properly solve this, one would need to add the possibility to
control reading from dll.d. I therefore never finshed this patch (and
lost it). I was indeed considering packaging scanbd for Fedora and ran
into the same problems. I therefore gave up the idea of packaging
scanbd.

Now I come to think of this again, it may be sufficient to skip reading
dll.d when we read the scanbd dll.conf (env. variable is set) but allow
dll.conf to read config files prefixed with dll.d, something like
dll.d/foo.conf. If we then add some code to scanbd (and possibly some
init files/systemd service files) to set the environment var in the
appropriate cases we might be able to solve the issue.
comments?
Kind regards, Louis