Hi all, Louis Lagendijk writes:
> On Sat, 2017-05-06 at 15:55 +0200, Wilhelm wrote: >> Am 06.05.2017 um 14:27 schrieb m. allan noah: >> > On Sat, May 6, 2017 at 5:52 AM, Louis Lagendijk <[email protected]> >> > wrote: >> > > >> > > Hi, >> > > Yesterday when I had a look at our bug tracker for any issues in >> > > my code I found >> > > https://alioth.debian.org/tracker/?func=detail&group_id=30186&aid=315004&atid=410366 >> > > This is an issue for scanbd integration that requires more >> > > flexibility for configuration of dll-loading: when scanbd is used >> > > users need to use the net backend only, but scanbd/saned need to >> > > be fed with the "normal" list of backends. >> > > I made a patch to dll.c where >> > > - It used the dll.conf with the name pointed out by env. var >> > > SANE_CONFIG_FILE if defined, if not >> > > - it tries to load a dll2.conf if it exists. This is meant to be >> > > a file dropped in thre sane config dir by scanbd. If that does >> > > not exist >> > > - it follows the existing code path. >> > > >> > > I added a #include statement in the config file so dll2.conf can >> > > include dll.conf if so required. >> > > >> > > I am in the process of testing and cleaningup. but my question >> > > is: >> > > should I commit this change so close to the freeze date? >> > > Documentation is still to be done, but I would still have 2 weeks >> > > for that. Alan, what do you think? >> > >> > I don't now recall the entire discussion around the guts of >> > scanbd's implementation, but you description sounds a little odd to >> > me. >> > >> > 1. If dll2.conf is created by scanbd, and scanbd is not running, >> > and the user uses scanimage or another frontend, he will >> > unknowingly load dll2.conf first. Even if dll2.conf #includes >> > dll.conf, it is still a behavior change. >> > 2. Do you not also need changes to saned to make this work? That >> > seemed to be the case in the earlier discussion. >> > 3. I think I would prefer a more clear name than dll2.conf, but I >> > cannot think of one :) >> >> From a scanbd point of view it would be suffcient to have either: >> >> 1) an env-var e.g. SANE_CONFIG_FILE which is normally unset and all >> sane-applications use the compile-time setting. scanbd can set this >> to an alternative (e.g. scanbd-dll.conf) file before starting saned. >> >> 2) give saned a -c <file> option >> >> I would prefer 1) > > Well 2 is not an option in my opinion as there is no way for saned to > pass an argument to the rest of saned. That is why I implemented 1). I don't understand why saned would have to pass arguments to the rest of saned. Can you explain? > The change to an alternative dll.file was driven by the fact that when > packaging scanbd you want to minimize the amount of configuration to be > done by the user. There's post-installation scripts that can take care of most of that and pre-removal scripts can restore things back to how they were. As far as I understand, the only thing the user needs to configure are the desired actions when a button gets pushed. - in /etc/scanbd/sane.d/ - add symlinks to all files (and directories) in /etc/sane.d - replace the /etc/scanbd/sane.d/dll.conf link with a copy - disable the net backend in /etc/scanbd/sane.d/dll.conf - in /etc/sane.d/dll.conf disable all backends You could prefix all lines with '#scanbd ' for example. - in /etc/sane.d/dll.conf enable the net backend I would also add a note that admins should make changes in /etc/scanbd/sane.d/dll.conf instead. - in /etc/sane.d/net.conf make sure localhost is enabled After that scanbd can just set SANE_CONFIG_DIR=/etc/scandb/sane.d and do its thing. On the off chance that sane-backends package upgrades add/remove conf files, you should probably also add a trigger to update the symlinks. Did I miss something? If not, why would we need to complicate the dll backend's configuration file handling if this can be handled fairly easily by package post-installation and pre-removal scripts? The only "wart" in the above is the pile of symlinks. But please read on as I am open to modifying the dll backend's conffile handling. Just not in the upcoming 1.0.26. I think it's all too last minute and could use some more thought and discussion. > If the scanbd package drops a dll2.conf file in > SANE_CONFIG_DIR there is no need for manual configuration. > > I am now implenmenting a #pidfile directive for in dll2.conf that will > check for the pidfile and fail processing of dll2.conf and fallback to > dll.conf. Hmm, #pidfile looks like a comment to me (and the few backends whose code I looked at). You probably should use something without a #. > The way I envisage this working is: > The package drops a dll2.conf file containing: > > #pidfile=/var/run/scanbd.pid > net > > so sane users see only the net backend if scanbd is active. Or there is a stale pidfile lingering around. I doubt that there is much you could do about that. It would be up to systemd (cough), the init script or scanbd to make sure the pidfile is removed, even in the case scanbd crashes. BTW, this could be simplified if scanbd creates that dll2.conf file as /var/run/sane/scanbd.conf at startup (and removes it on exit) and the dll backend modified to prefer that file unless explicitly told to ignore it (by scanbd via an environment variable). When ignoring, the regular conffile handling kicks in and dll.conf is searched for in all the directories given in SANE_CONFIG_DIR if defined. If SANE_CONFIG_DIR ends with a path separator, : on Unix, $PWD and $sysconfdir are searched as well. If SANE_CONFIG_DIR is not defined, the search looks in $PWD first and $sysconfdir next. # BTW, I just noticed that the use of $PWD is open to abuse by frontends # that call chdir() before sane_init() and backends that chdir() before # searching for their conffile. > The default dll.conf remains unchanged, but net should be commented out > > Scanbd uses dll.conf (sets SCAN_CONFIG_FILE=dll.conf) In my /var/run/sane/scanbd.conf scenario, this is where scanbd needs to signal the dll backend to ignore that file. > The only configuration required from the user is: > - comment net from dll.conf if not already done > - populate net.conf with localhost That's still food for post-installation and pre-removal scripts. The idea being that you want to use scanbd if you install it. BTW, you want to add localhost to net.conf. There may be other hosts configured already. > I changed the name of the alternative config file to dll-override.conf > (but remain open for better alternatives). I think that /var/run/sane/scanbd.conf is pretty self-explanatory. You could also go for /etc/sane.d/scanbd.conf but that might be just a tad confusing as there is a /etc/scanbd/scanbd.conf as well. > I hope that these changes (dll-override.conf as name + check for > pidfile) address concerns people may have so I can commit the changes > today and be in time for 1.0.26. > > Comments anybody? See above ;-) Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join -- sane-devel mailing list: [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to [email protected]
