[sane-devel] Scanbd and /etc/sane.d

[Louis Lagendijk]

I am sorry for the long post, but I am afraid that I need to provide
a lot of background.

The issues
------------
As you may recall I am packaging scanbd for Fedora. There are a few 
issues that make this a bit challenging:

1) In order to create a good user experience, I want the package to
configure the system as much as possible without any user intervention.
The sane configuration is giving me a bit of a head ache here.
In the ideal situation I would add a few files to the system and 
everything works out of the box. 
This is where dll.conf is giving me problems: user scanning apps 
require a dll.conf that has only the net backend listed, scanbd (or 
saned for that matter) need the normal dll.conf. 
With rpm I can not do this, as the scanner apps use the 
sane.d/dll.conf file. So I would need to change this. Changing files 
owned by other rpms if not allowed -> checkmate.

2) Even when I solve this, sanner aps would still inherit all the 
backends listed in one of the files in the sane.d.dll.d directory. 
But that is not what I need, but I can't see a way to control this, 
other then removing these files. But these files are owned by other 
rpms and will get re-added when the packages are updated or 
additional ones added, I have no way of controlling this-> 
check mate again

The other thing is for the daemon I can set an own SANE_CONFIG_DIR,
but then I need to copy all backend config files as well, OR set
SANE_CONFIG_DIR with a terminating dir separator so that backend
configuration files get searched in the standard search path as well.
This will work but it is not exactly intuitive.

It would be very nice if we could keep all configuration in one place:
the normal sane.d directory.

My proposal:
------------
I have written a patch to dll.c that tries to load a <prefix>-dll.conf
before it tries to load dll.conf. 
The prefix can be set with a new environment variable SANE_DLL_PREFIX.
The prefix defaults to "default" (so we try to load 
default-dll.conf) unless SANE_DLL_PREFIX environment variable is
set). 

If <prefix>-dll.conf exists anywhere in the search path it gets used. 

If it does not exist, we fallback to dll.conf. 

With this patch, the distribtion's sane package is expected to ship 
with only dll.conf. As no xxx-dll.conf files exist, the standard 
dll.conf gets used in all cases. 

If we now install a package that needs different dll.conf files, it
drops two new dll.con files in sane.d: default-dll.conf (with probably
only the net backend) and scanbd-dll.conf (or saned-dll.conf) which is
as symbolic link to dll.conf and get used for scanbd and/or saned.

This works nicely, except for the loading of the files in dll.d. This is
unfortunately hard coded in dll.c. I have added a directive @dll.d that
can be included in dll.conf to trigger the reading of files in dll.d. 
So where-ever dll.conf contains a @dlld directive the directory gets
searched and any configuration files in there get processed.


I personally prefer option a, but I am unhappy about the
incompatibility this gives. But option b gives slightly different
semantics for dll.conf and <prefix>-dll.conf. That is maybe even worse. 

This mechanism could be used for saned too. I envisage that saned gets
packaged separately and would add default-dll.conf for users with only
the net backend and  saned-dll.conf as a symbolic link to dll.conf.  

Other suggestions
------------------
I have tried to start a discussion on this before. 
Wilhem then suggested the following:
> I can imagine to more alternatives:
> 
> 1) use env-var SANE_CONFIG_FILE for getting the filename of the real 
> dll.conf in the SANE_CONFIG_DIR
> 
This could be done if you people prefer so, I used <prefix>-dll.conf as
that is more intuitive in my opinion. But this is in itself just a small
variation on the implementation as described above.

> 2) add a function to the programming interface to set the name / dir for 
> the config-file (sane_init)
> 
This would be different from the mechanism used for SANE_CONFIG_DIR, so
I regard it less desirable. It would also require changes to saned as
saned would also want to use this mechanism.

Conclusions/ questions
-----------------------
I propose to go for 1a and update our standard dll.conf with @dll.d as
the first line, but I have 2 questions:

1) are you ok with the approach described here?
2) if so, how do you prefer we handle the dll.d directory:
   a) change the default dll.conf to include @dlld
   b) honour @dll.d where it occurs, but still hardcode it in case we are
      using dll.conf?

Comments? Does anybody have better suggestions? 
I believe that a solution to this issue is desirable so it becomes much
easier for distributions to  ship a pre-configured saned too.

Looking forward to your feedback as  I do not want to create an
incompatibility without discussion on the list here.
Louis