Bug#587279: debian-policy: section 2.2.1 needs some tweaking
On Tue, Mar 13, 2012 at 11:27 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I understand this section very well, and even with that lead-in wording,
>> I contend that sufficient ambiguity remains that additional clarity is
>> needed. Otherwise, it wouldn't have been so difficult to deal with bug
>> #449497, which essentially turned into a wontfix.
>
> No, that bug is a different argument (the one about what it means to
> "require software").
It's more nuanced than that.
Think about it this way. Say the remote firmware files that getweb
currently fetches were instead put in a package called
foo2zjs-nonfree. That package would (of course) have to be located in
non-free, and any packages depending on that would need to be located
in at least contrib, right?
Now the majority of foo2zjs doesn't depend on those files, but it can
make use of them if/when they're available. Now that there is no need
to fetch external files, getweb is dropped from the package. Based on
those two facts, its obvious that this new version of the package
appropriately belongs in main.
For the sake of argument, lets assume that the upstream build system
doesn't put the foo2zjs-nonfree files into the right place as expected
by foo2zjs. In the usual Debian world, the foo2zjs-nonfree maintainer
would write some fix-up scripts that would be a part of the that
package and it would be a non-issue since all of it would be in
non-free.
Again, for the sake of argument, let's assume that the foo2zjs-nonfree
maintainer is opposed to including those fix-ups directly into the
package for whatever reason (as an aside this sort of mimicks the
current upstream author's rejection of distro packaging of his
software). So someone comes along and writes a foo2zjs-getmove
package, which moves the nonfree files into the right place that the
foo2zjs package needs.
Now, where does foo2zjs-getmove belong? It only serves to support a
non-free component. More importantly, what are the Depends and
Recommends of that package? I would content that it would be a
"Depends: foo2zjs-nonfree", since the package itself can't do anything
without that.
Admittedly, this is a convoluted situation for normal Debian packages,
but it accurately mimicks the current situation if it were done with
packages rather than fetching scripts, and thus is valid as a
gedankenexperiment.
> I don't have anything new to say about that bug that I didn't say at the
> time.
I don't think you had commented at the time.
> I continue to believe that the current bug state is correct, and
> that your position on that bug is not correct, although I understand where
> your position comes from and I don't think it's unreasonable.
Opinions are malleable (wrong and right are all a matter of
perspective). This is something sufficiently nuanced that I think its
worth sufficient pondering to really get it right. If you haven't
spent much time pondering those nuances, it's easy to assume
perspective of the status quo.
>> The problem is that even though the lead-in uses the term "software",
>> the actual "must" requirements use the term "package".
>
>> Thus, a liberal reading of policy leads to the conclusion that if there
>> isn't an explicit dependency on a package, then it's ok to have a script
>> or plugin in main that makes use of non-free.
>
> Here is the complete text:
>
> The main archive area comprises the Debian distribution. Only the
> packages in this area are considered part of the distribution. None of
> the packages in the main archive area require software outside of that
> area to function. Anyone may use, share, modify and redistribute the
> packages in this archive area freely[4].
>
> Every package in main must comply with the DFSG (Debian Free Software
> Guidelines).
>
> In addition, the packages in main
>
> * must not require or recommend a package outside of main for
> compilation or execution (thus, the package must not declare a
> "Pre-Depends", "Depends", "Recommends", "Build-Depends", or
> "Build-Depends-Indep" relationship on a non-main package),
>
> * must not be so buggy that we refuse to support them, and
>
> * must meet all policy requirements presented in this manual.
>
> The words "in addition" have a specific meaning in English. The bullet
> points do not replace all the text that comes before them.
Right, I wasn't trying to say that. My point was more that the
lead-in paragraph as it is now is only descriptive, but given the
wording doesn't actually lay out any of particular requirements (more
so it lays out the ideals of main). The requirements themselves
actually start with, "Every package in main must comply...." then
continues with "In addition to" and then the bullets. Those actually
binding sections never use the term "software", so the obvious
interpretation is that policy only places requirements on "packages",
and even more importantly seemingly only their control fields, not
their actual components (giving things like getweb a pass).
> I suppose we could add a "must" to the "None of the packages in the main
> archive area require software outside of that area to function" sentence
> with some rephrasing, if it would result in having fewer arguments about
> this, but I really don't believe the meaning is unclear.
It's not unclear per se, but there remain ambiguities in terminology
making it possible to interpret it in various slightly incompatible
fashions: the choice of the term "package" vs. "software" makes it
appear ok to have non-main "software" depends/recommends but not ok to
have "package" depends/recommends. It seems like a more correct
policy would apply uniformly to all software elements in the archive,
not just packaging and their fields.
Best wishes,
Mike
Reply to: