[sane-devel] SANE2, what do we want ?
jb at jblache.org
Mon Apr 7 10:21:30 UTC 2008
Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>> Not exactly free by my book, I'm sorry but it really does make a
> 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
>> 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
This change will be reverted after the Lenny release.
> If libsane no longer works because libsane-extras is not installed,
> then they aren't exactly "extras" in my book ;-)
The package is only separated from libsane because I wanted a small
independent source package that I could upload as frequently as I
wanted without overloading our buildd infrastructure with something as
big as libsane.
>> And now I no longer have to ask "do you have libsane-extras
>> installed?" in bug reports, which is a selling point, really ;)
> But that's just convenience. Rather than Depends: you could have made
> it a Recommends:.
Obviously the wording and smiley weren't enough, I'll use XML markup
next time :-/
>> Use a diversion on libsane-epkowa.* to handle that, that's the best
> 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.
> 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.
>> - no way I am extracting the files from a collection of RPMs every
> Apart from the interpreters, which files, if any? Everything is in
> the "source" tarball, AFAIK.
Nothing else, only the interpreters.
Julien BLACHE <http://www.jblache.org>
<jb at jblache.org> GPG KeyID 0xF5D65169
More information about the sane-devel