[Foo2zjs-maintainer] Bug#449497: foo2zjs dispute

[Giacomo A. Catenazzi]

Note: I'm not a CTTE member.

Steffen Joeris wrote:
> Maintainer:
> --------------
> 
> The problem is as follows. The submitter sees the inclusion of the
> getweb script as a violation of the DFSG. The script is provided by
> upstream to download non-free firmware from his upstream webpage.  The
> package includes documentation in README.Debian and a GUI interface
> (hannah-foo2zjs) around the getweb script for the user's
> convenience. Some printers need this non-free firmware to run, others
> don't.  More information can be found in the bugreport. Could we
> please ask you to settle this dispute?
> 
> 
> Submitter:
> --------------
> 
> The submitter sees the getweb script's dependencies on external
> data/files as potentially dangerous.  Once the package enters stable,
> upstream changes (moving/modifying files, etc.) can break
> functionality -- leading to a package that can no longer be considered
> "stable."  External dependencies also potentially leave users
> vulnerable to security risks (the upstream site could be spoofed or
> hijacked and malicious files hosted instead of the legitimate firmware
> files).  Also, the submitter views external dependencies as a possible
> violation of the spirit of the debian policy, which currently is not
> explicitly clear on the issue.  Section 2.2.1 says "... the packages
> in main must not require a package outside of main for compilation or
> execution (thus, the package must not declare a 'Depends',
> 'Recommends', or 'Build-Depends' relationship on a non-main package)."
>  This makes the policy clear about "packages," but it does not address
> dependencies on other external non-packaged non-free files.  It is the
> submitter's belief that Debian's policy should be reworded for clarity
> on situations such as this.

It is not a DFSG violation, because the file are not distributed
by Debian, but I think it violated the policy.

I think Debian should not assume a machine on the net, so I
would interpret "main" in the stricter way.

I don't find an overkill to make a separate package for the
download script. As you will see, maintaining such script
will be complexer and in case of layout change, it don't
requires a updates from most of the package user.

The changing of remote layout is an important problem: the package
could become unusable thus potentially a RC bug, which should not
happens on other bugs in main.
The "contrib" section includes (historically) also the reduced
quality package, so the uninstability of a contrib package could
be temporary accepted.

ciao
	cate