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 -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org
