[sane-devel] SANE2, what do we want ?

[Olaf Meeuwissen]

Julien BLACHE <jb at jblache.org> writes:

> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>
> Hi,
>
>>> Not exactly free by my book, I'm sorry but it really does make a
>>> difference.
>>
>> As free as the epkowa backend software is concerned, it is free.  The
>> fact that it does not support all the scanner models you would like it
>> to without a non-free extension does not change anything to the fact
>> that the backend software is free-as-in-freedom.
>
> You can disagree all you want, I'm pretty sure the FSF stands on my
> side.

The FSF will very likely concede the fact that the backend is free to
the letter of the license.  At the same time, they will very likely
remark that the backend is not really free in spirit.  AFAIK, the FSF
has always allowed (but not encouraged) inter-operation with non-free
components.  The GPL FAQ includes explanations for several scenarios
that want to cater to non-free extensions or use non-free components.

>>> The udev rules in libsane-extras were buggy; it was absolutely harmless
>>> until I migrated to a new layout for installing udev rules, then all
>>> hell broke loose and the only option to avoid rendering systems
>>> unbootable was to have that dependency.
>>
>> Why was that the only option?  If thee udev rules in libsane-extras
>> were buggy, why could you not fix that?
>
> Because that by itself doesn't fix the problem on systems where
> libsane-extras is removed but not purged. Hence the dependency was
> needed to reinstall libsane-extras with a fixed rules file on those
> systems.
>
> This change will be reverted after the Lenny release.

I see but don't quite understand so I'll take a look later.

> [snip]
>>> Use a diversion on libsane-epkowa.* to handle that, that's the best
>>> option.
>>
>> What about suggestions for the conffile?  I was gonna put them in
>> dll.d but that doesn't look as attractive as it did before
>> libsane-extras became a Depends:.
>
> You can divert the conffile, too.

Considering the fact that iscan and libsane-extras will be stepping on
each other's toes in this area (as far as the backends are concerned),
we should probably work something out.  IIRC, diversions require
mutual agreement on both sides.  We can do this off-list.

>> With 12 interpreters at the moment (and counting :-() and the need to
>> cater to two C++ ABIs, the non-free interpreters, which are only
>> needed by a select few people to begin with (and even fewer will need
>> all the interpreters) would bloat the packages out of any proportion.
>
> I understand perfectly, I also understand that there's nothing
> preventing them from giving access to the directory on the webserver
> where the packages are stored so it's possible to retrieve them all in
> one go if needed.

In terms of technology, you are absolutely right.  We could even set
up repositories so you could just use apt-get or yum to install iscan.
Unfortunately, technology does have the final say in this issue.

Hope this helps,
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/