Flatpaking of Paperwork: Issues with locale-specific files and scanner drivers

[Jerome Flesch]

I think I will have to ask users to enable Saned. Currently, it's probably the easiest way for devs and users.


13 octobre 2017 16:27 "Bastien Nocera" <hadess at hadess.net> a écrit:

> On Fri, 2017-10-13 at 12:03 +0200, Alexander Larsson wrote:
> 
>> On Thu, 2017-10-12 at 14:09 +0200, Bastien Nocera wrote:
>> On Thu, 2017-10-12 at 13:45 +0200, Alexander Larsson wrote:
>>> 
>> 
>> <snip>1
>>>> - Paperwork uses Sane to access scanners. However, Sane only
>>>> has
>>>> user-land drivers (most uses libusb I guess). Most users don't
>>>> have
>>>> saned (Sane daemon) enabled on their system. Therefore, libsane
>>>> usually access directly the scanner(s) using the user-land
>>>> drivers
>>>> bundled with it. I can easily package all the open-source
>>>> drivers
>>>> of
>>>> sane-backends with Paperwork, but some people have scanners
>>>> requiring
>>>> proprietary drivers. For instance, my Brother scanner is
>>>> installed
>>>> using a shell script provided by Brother, and this shell script
>>>> download and install .deb files.
>>> 
>>> You can make an app extension point for this, then people can
>>> package
>>> drivers either as flatpaks, or by using "unmanaged extensions"
>>> which
>>> are just a correctly named directory on the host acting as an
>>> extension.
>> 
>> We still need to think of a way to handle "generic" USB devices. I
>> think that using saned in the same way we use PulseAudio, Pipewire
>> and
>> co. (authorisation agent) would probably be the best way to solve
>> the
>> problem for Flatpak.
>> 
>> It's quite a bit of work, but that's pretty much the only way to
>> get
>> hotplug support, remote device discovery, all handled in a way
>> that'd
>> integrate well with Flatpak.
>> 
>> I don't think that each scanning application having its own SANE
>> stack
>> is a good way to solve that problem.
>> 
>> I think this is true, but it also makes packaging such apps much
>> harder, as you suddenly need to convince distros to change how sane
>> is
>> packaged, no?
> 
> I'm not sure it's that different to expecting other sandbox-aware
> daemons to be installed in the distribution.
> 
> You also would not be able to use any hotplug support. So you can't
> launch your scanner app and then plug it in, because of the way the
> devices are set up in the sandbox.
> 
> Ideally, saned is pretty much exactly what the doctor ordered, and
> already supports everything using the sane libraries directly supports
> (enumeration, accessing all the features of the scanner), has a stable
> ABI/protocol and maybe supports authorisation in a modular way that can
> be integrated in gnome-shell.
> 
> And though saned wouldn't live in the sandbox, we can still lock it
> down quite a fair bit with systemd's lockdown features.
> 
> Do any of the SANE/saned developers care to comment?
> 
> Cheers