Re: foo2zjs dispute
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
Reply to: