On Sat, Feb 22, 2014 at 09:31:08PM +0100, Markus Koschany wrote: > On 22.02.2014 01:09, Bas Wijnen wrote: > > Policy 2.2.2 doesn't use the technical term "execution", but the more > > subjective "which require software outside of the distribution to either > > build or function". I don't think this is a mistake. > > I was referring to § 2.2.1: > "must not require or recommend a package outside of main for compilation > or execution" 2.2.1 also says: None of the packages in the main archive area require software outside of that area to function. The line you quote just makes explicit that a technical dependency is certainly not allowed; it doesn't say everything else is. > I think we all agree so far that residualvm fulfills this requirement. All I know about the package is from this thread, but from what I read here, I would say that residualvm should have a Recommends: on non-free data, because while it is possible to start the executable without them, and it won't crash, it is also not usable. So it fits the description: The Recommends field should list packages that would be found together with this one in all but unusual installations. (policy 7.2) While it is technically possible to omit the Recommends, or downgrade it to a Suggests, and then claim that the package can go into main, I think it should be obvious that this is not following the spirit of policy. > Since the license of the game data allows modifications and is DFSG > free, everyone has the right to modify the games. Hence both of them > fit perfectly well into main. A binary blob with a free license is not acceptable for main. > § 2.2.2 again where the policy talks about software not data. Software is unfortunately not defined by policy. But it is defined in a GR, and strictly speaking, you seem to be correct. We decided (among other things) that: > the Debian Project: > > Reaffirms that programmatic works [...] must include the form that the > copyright holder or upstream developer would actually use for > modification. > > Strongly recommends that all non-programmatic works distribute the form > that the copyright holder or upstream developer would actually use for > modification. (https://www.debian.org/vote/2006/vote_004) So here again the "preferred form of modification" type of definition is used. But it's written slightly differently, and in the case of things that do not have source code anymore, we have decided that binary blobs can in fact be source. We have also decided that data files are not required to be free; we only "strongly recommend" it. However, I think our team should follow this recommendation and keep any data without sources out of main. But I was wrong about those scummvm games; since the source is lost, we decided that those binary blobs are source, and so they can indeed go in main. (I remember voting in favor of this; this is not what I meant. Ah well.) It still doesn't change much about residualvm though. Without free data, it needs a Recommends: on a non-free package (even if only theoretically; if the data isn't packaged), which is in violation of policy 2.2.1. The GR says we are allowed to ignore this, because it is not a programmatic work (although that is debatable, too; there are scripts in that data). I really think we should follow the recommendation though. > But as I said before what concerns me the most is the fact, that we > are inconsistent when it comes to the question of "main vs. contrib". > If we can accept scottfree and quakespasm in main, residualvm should > be tolerable, too. I agree that we should be consistent. But that doesn't mean automatically throwing everything in main. It means making a decision, and possibly removing those other things from main. Thanks, Bas
Attachment:
signature.asc
Description: Digital signature