[sane-devel] sane-backends release 1.0.26 schedule

[Louis Lagendijk]

On Sun, 2017-05-07 at 07:34 +0900, Olaf Meeuwissen wrote:
> 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.n
> > > > et>
> > > > wrote:
> > > > > 
> > > 
> > > 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?

A terribly confusing typo: I meant sane (or libsane that by default
runs dll.c. Libsane does not have the possibility to pass any arguments
to it.  So saned could not pass the argment to libsane (or dll.c for
that matter). Or it would have to use a environment variable anyway.
that is what I tried to convey.


> > 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.
> 
That would not solve the dll.d issue though, sigh (see below for more
details).

> 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.

This would not work for dll.c updates on rpm based systems at least:
new versions of config files will be stored as dll.conf.rpmnew.  So at
least on rpm based systems not touching dll.conf is desirable. A
restore of the dll.conf from a scanbd removal can not restore the
dll.conf to the latest dll.conf. 

Hence my preference to make an dll-override (see below for an
alternative solution) and leave dll.conf alone (and only load the
backends mentioned in that alternative dll.conf file and ignore dll.d
if an override is specified. I am still unhappy about the inconsistent
behaviour in that case though).
I only wish that dll.d was only loaded from a directive in dll.conf. 
Dll.d is a nasty problem. Any better suggestions for that?
> 
>  - 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
> 
Copying dll.conf + symlinking the rest should be ok. I am happy with
this part of the solution.

Modifying sane config files I am not sure about. I seem to recall that
modifying other packages config files is not allowed or at least
frowned upon for fedora. So this would still be a manual action for the
user.

Postinstall for scanbd could do the copying/linking as you propose.
This solves the scanbd side of things. The problem is on the sane
(default) side as we have dll.d to deal with.

> 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.
> 
Again, I need to check the rules. 

> 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.
> 
I am not too worried about that part.

> 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.
> 
I fully agree on not including this now. I started my initial mail
stating that  I realized that I was very late taking this on. I said in
the report on Alioth that it could take a long time and most likely
would miss 1.0.26. 

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 #.
> 
pidfile does not work anyhow, when scanbd is started from systemd it
will not have a pid-file. I should have known as I wrote the systemd
units for scanbd. I need to find a better start for directives, but I
selected # as it is now that start of a comment and could not interfere
 with any backend names (although the all start with [a-z] for now.
Using # as start for any directive made sure that I would not create
new problems. But I am open for any suggestion. I consider what I have
now more as a proof of concept, so we can change whatever we need.

> > 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.
> 
Yeah systemd or an init script could create another file and remove it.
But that still leaves the possibility that scanbd would crash or hang
without the init system knowing about it.  

> 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
Why not create a /var/lib/sane.d where scanbd or any other program can
place a dll.conf at start and remobve it at exit? 

> 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.
Let's just add /var/lib/sane.d in the search path?

> # 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.
> 
Should we not completely remove $PWD on Unix then? It seems to be a
security liability anyhow (just imagine what happens if something just
places a config file in the directory where the user running a program?
 Adding ~/.config/sane.d to the search path might be a better solution
for the user that wants an own configuration.

> > The default dll.conf remains unchanged, but net should be commented
> > out
> > 
But we then should ignore dll.d

> > 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.
> 
See above: /var/lib/sane.d /dll.conf for overrides may be a small
burden for scanbd and is open for other users. And it removes a lot of
the burden for sane. when scanbd starts it just creates that dll.conf
file and we are done. 

Thanks for the fruitdull discussion guys!
Cheers, Louis