Re: [RFS] minigalaxy - simple GOG client
(I've rearranged the paragraphs I'm replying to because I think the
ones I've put first might make this clearest)
On Fri, 08 Jan 2021 at 20:17:47 +0100, Matija Nalis wrote:
> 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?
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"?
If we had a package called cyberpunk2077-launcher, described as a game,
that downloaded Cyberpunk 2077 from gog.com and ran it, then I think
that would be contrib for the reasons you describe.
If we have a package like lgogdownloader or minigalaxy, described as a
tool for managing/launching games, that lists *all* the games on gog.com
and helps you to download and run whichever ones you select, then I
think that's suitable for main - even though, mechanically, it's doing
most of the same things that my hypothetical cyberpunk2077-launcher does.
> On Fri, Jan 08, 2021 at 03:42:54PM +0000, Simon McVittie wrote:
> > 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"?
"it" in that sentence means the manager/downloader.
To be more specific about this:
Imagine we somehow had a GOG game in the archive - again, let's say
Cyberpunk 2077. (We can't, because that would be copyright infringement,
but imagine for a minute that we could.)
Would minigalaxy have Depends: cyberpunk2077? I don't think that would
make sense: there are lots of other GOG games, but also, this dependency
would be the wrong way round. You don't install Cyberpunk 2077 in order
to make minigalaxy work.
It's more like the other way round - you *might* install minigalaxy to
make Cyberpunk 2077 work better, or to make CP2077 work at all, or to
make it easier to download CP2077, or to make it *possible* to download
CP2077. So it would perhaps be closer to the truth to say that CP2077
depends on minigalaxy.
> 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?
What I'm saying is that if the app's function *is* to download things,
and it isn't too specific about the things it downloads, then the things
it downloads are not really something that it "depends on" - they're
more like the data that it works with.
A word processor works with word processor documents, but when considering
whether to allow it in main, we don't say that it depends on word
processor documents. A web browser works with web pages or web servers,
and is not useful if you don't have any web pages, but when considering
whether to allow it in main, we don't say that it depends on web pages
or web servers.
Similarly, I think it's reasonable to say that lgogdownloader and
minigalaxy work with games, rather than depending on games.
> 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's a dependency, because the purpose of Firefox isn't "download
and run firefox-precompiled.x86", the purpose of Firefox is to view web
pages. If Firefox was packaged in that way, and you did't have the binary
blob, then Firefox couldn't do what the package description says it's for
(download and view web pages). So if a browser was packaged like that,
it would go in contrib.
I don't think it actually matters for our current policies whether the
blob in question is Free or not: if we had a firefox-via-flatpak.deb that
contained a script that would automatically install the Firefox Flatpak
app from Flathub (or a Snap or AppImage app, or any other equivalent
that doesn't come from Debian main), then our current policies would put
firefox-via-flatpak.deb in contrib, even though the Flatpak app that it
would download is Free Software.
However, flatpak - the program that downloads and runs any Flatpak
app from any source that you ask it to - is in main. Do you see the
difference there?
smcv
Reply to: