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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPDpqdha1FNr=bt35jhdrjxf6kst9qyo5s9r-sxva7...@mail.gmail.com
