Re: [RFS] minigalaxy - simple GOG client

Stephen Kitt <[email protected]> Fri, 8 Jan 2021 22:31:05 +0100
Newsgroups	gmane.linux.debian.devel.games
Message-ID	<[email protected]>
On Fri, 8 Jan 2021 20:17:47 +0100, Matija Nalis
<[email protected]> 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
signature.asc (application/pgp-signature, 833 B)