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