[sane-devel] sane-backends release 1.0.26 schedule

Sat May 6 22:34:26 UTC 2017

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 <louis at fazant.net>
>> > 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