On Fri, 8 Jan 2021 20:17:47 +0100, Matija Nalis <mnalis-debiangames@l.voyager.hr> wrote: > On Fri, Jan 08, 2021 at 03:42:54PM +0000, Simon McVittie wrote: > > On Fri, 08 Jan 2021 at 15:16:31 +0100, Matija Nalis wrote: > > > Basically, you can ask yourself a question "Would people still be > > > using this package, if all functionality that downloads stuff > > > outside of Debian "main" archive was removed from it?" > > > > This can't be where the line gets drawn in practice, because there are > > lots of programs in main whose primary purpose is to download things > > that aren't in main, such as web browsers and IMAP/POP email clients. > > My bad, I wasn't explicit enough: by "stuff" I meant the subject of > the mail, eg. non-DFSG game executables & data (if that is what > GOG provides?) That is what GOG provides. [...] > > Another question that might give something closer to the right answer > > is: if we imagine the non-main software that it downloads/loads/uses > > existed in main, contrib or non-free (whichever was appropriate), > > would the manager/downloader have a Depends or Recommends on it, or > > something weaker? > > I did not manage to parse that, sorry. Are you talking here about GOG > game having depends on minigalaxy, or minigalaxy depending on GOG.com > games? What is meant by "it" in "the non-main software that it > downloads/loads/uses existed in main, contrib or non-free"? > > Or is it about difference in using package control headers like > Depends/Recommends vs. having dependencies outside debian packages > (eg. wget/curl)? See comment below. This is another way of putting what Policy says: > 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, Build-Depends-Indep, or Build-Depends-Arch > relationship on a non-main package unless that package is only listed as > a non-default alternative for a package in main), > > * must not be so buggy that we refuse to support them, and > > * must meet all policy requirements presented in this manual. Simon’s test is as follows: if package A is designed to download non-free software B, would package A actually depend on B? That’s pretty much the same as “must not require or recommend a package outside of main for [...] execution”. Even if you don’t own anything on GOG, you can still install and run lgogdownloader and minigalaxy. They won’t be *useful*, but they will still work. So following the letter of Policy, they can go in main. > > In the case of lgogdownloader and minigalaxy, I suspect the answer > > would be no, because they don't require any particular game in order to > > do what they do. What they do is "download/manage games from GOG", > > and they can do that whether or not you have any particular game > > installed: the same reasoning as Firefox not needing a dependency on any > > packages that contain HTML. > > I'm trying to understand this... When you say "dependency" do you > mean only on "Depends:" (and maybe "Recommends:") header in control > file of the package, or any *actual dependency* needed by the app to > run and perform its function? > > Ie. if said firefox would not work at all without downloading some > non-free binary blob from getfirefox.com and running it, would that > be considered "dependency" in paragraph above, or not? Yes, that would be a dependency, and it would result in Firefox being in contrib. > And in that light, would such firefox package be considered a "main" > or "contrib" material? > > Would that answer differ if that was "Depends:" header to nonfree > package in control file (instead of non-free library downloaded with > curl)? No, the answer would be the same. > To me as a newbie it looks like it would be mostly irrelevant > implementation detail (if it downloads from debian.org/non-free or > getfirefox.com/non-free) but your answer seems to imply that it is > different? (Then again, english is not my native language so I > apologize if I misunderstand) > > > I think that test also gives the right answer for things like the > > old flashplugin-nonfree package, where the purpose of the package was > > "play Flash animations", and the fact that it did that by downloading > > the plugin out-of-band is an implementation detail. If it could have > > (legally) achieved the same goal by having a copy of the plugin *in* > > non-free, it would have had a Depends on the actual plugin instead. > > I have not had experiance with it, but I looked it up now. > > If I understand correctly, flashplugin-nonfree was a "contrib" > package, so I assume it was DFSG code which downloaded and executed > non-free code from adobe.com (or somewhere similar)? Is that correct? That is correct. > If correct, what is a distinction of flashplugin-nonfree from > minigalaxy (or from lgogdownloader)? Do they not also exist only to > download and execute non-free code from gog.com, and so should be in > same "contrib" as was the case with "flashplugin-nonfree"? > > I'm obviously missing something (maybe because I am not a gog.com > user, or because my english is not good enough, or because I > fundamentaly misunderstand main/contrib difference, or combination > of above). Another way of thinking about this is to consider that GOG could provide DFSG-free software on their platform (and in fact they do, since they ship games which are also in Debian, such as Lure of the Temptress, with a DFSG-free installer, ScummVM, and installer, MojoSetup), and the client wouldn’t change. Likewise, someone could implement a DFSG-free clone of Galaxy, and the client wouldn’t change. See also emulators: the general rule in Debian is that, even if no known DFSG-free program exists to run in a given emulator, if that emulator *requires* no non-free software to function, it can go in main. This line of reasoning does fall over somewhat when one considers game engines; the rule there in Debian is that if enough game *data* is available to provide a featureful game, then the engine goes in main, otherwise it goes in contrib. The theoretical possibility of future availability of DFSG-free game data doesn’t help. See for example rocksndiamonds. Likewise, game-data-packager, of which Simon is one of the main maintainers, is in contrib, with the following reasoning: > The game-data-packager package is Free Software but cannot be part of > Debian. Its purpose is to repack specific non-free and non-distributable > data files, so it depends on software (data) outside Debian to function. > As a result, it is distributed in the 'contrib' archive area (see Debian > Policy §2.2.2 for details). I realise that all this is somewhat open to interpretation, and I can understand that users who never want to run non-free software could object to the presence in main of software whose purpose is ostensibly to provide access to non-free software. I tend to rely on a strict interpretation of Policy at the packaging level, and since lgogdownloader and minigalaxy don’t have any package relationships with packages in contrib or non-free, and are functional without downloading anything else (and their function isn’t altered by downloading anything else). Regards, Stephen
Attachment:
pgpoVAMl_2OKl.pgp
Description: OpenPGP digital signature