Re: [gentoo-dev] SRC_URI="gogdownloader://..."

[Daniel Campbell]

On 10/02/2016 01:48 PM, James Le Cuirot wrote:
> Hi guys,
>
> As the newest member of the games team, I've had a somewhat
> off-the-wall idea. Like many gamers, I have a sizeable collection of
> games purchased from GOG.com. There have been efforts to package some
> of these, mainly in overlays, and I'd like to see more in the tree.
>
> There are basically 3 methods for downloading their games. The first is
> manually from the web site. The second is via their Galaxy client,
> which is not yet available for Linux. The third is via their
> "gogdownloader" links, which were created for their older client. This
> client is no longer maintained but an open source alternative for Linux
> called LGOGDownloader is still active.
>
> GOG have not said that the gogdownloader links are going away. They
> have simply said that the API is subject to change, which suggests that
> they are also used by Galaxy. In any case, I'm sure that LGOGDownloader
> will adapt.
>
> So wouldn't it be great if Portage could handle these gogdownloader://
> URLs? Before you throw your arms up at what appears to be proprietary
> nonsense, rest assured that this protocol is really just HTTP with
> authentication via OAuth. No doubt they chose their own scheme so that
> these links would fire up in their own client. This benefits us too as
> Portage uses the scheme to determine which fetch command to use.
>
> I recently added LGOGDownloader to the tree and some initial
> experiments with Portage have proved fruitful. Here are the key bits of
> an example ebuild.
>
> SRC_URI="gogdownloader://tomb_raider_1/en1installer1 -> setup_tomb_raider_${PV}.exe"
> IUSE="gogdownloader"
> RESTRICT="!gogdownloader? ( fetch ) mirror"
> DEPEND="games-util/lgogdownloader"
>
> pkg_nofetch() {
> 	einfo "Please purchase and download from GOG.com, etc…"
> }
>
> Some of this could go into a gog eclass. I've seen one in an overlay
> already. Ebuilds that support non-GOG sources could put this stuff
> behind a gog USE flag.
>
> I thought I would need pkg_pretend but I didn't realise that Portage
> attempts to fetch twice, once during the parallel fetch and again at
> build time if the first attempt fails. This means that even though you
> might not have lgogdownloader the first time, you will have it because
> of DEPEND the second time.
>
> The problem is that you will still have to configure Portage for this
> protocol manually unless it is added to the stock make.globals. Could
> this be done? If only everyone had make.conf as a directory then I
> could simply drop a file in there but even I don't. Paludis has the
> upper hand here as it supports several locations where you can drop
> "fetcher" configuration files. The configuration for Portage looks like
> this.
>
> FETCHCOMMAND_GOGDOWNLOADER="egogdownloader --output-file \"\${DISTDIR}/\${FILE}\" --download-file \"\${URI}\""
> RESUMECOMMAND_GOGDOWNLOADER="egogdownloader --output-file \"\${DISTDIR}/\${FILE}\" --download-file \"\${URI}\""
>
> egogdownloader is a small wrapper script that I have attached. It
> obviously simplifies what is needed above but also allows users to use
> the tool manually if they really want.
>
> lgogdownloader writes to ${XDG_CONFIG_HOME}/lgogdownloader and doesn't
> include a command line option to change this but we can obviously just
> set XDG_CONFIG_HOME to /etc. Portage already executes fetch commands
> with umask 002 but I added that for manual use. This ensures the
> configuration will always be writeable by those in the portage group. I
> had to write a patch (submitted, not yet in Portage) to add an option
> that prevents lgogdownloader from chmoding the sensitive files to 600.
>
> So what's the < /dev/null for? We don't want lgogdownloader to prompt
> for input and this effectively kills that. It normally prompts for your
> credentials if you're not already logged in or your session has
> expired. This behaviour actually seems broken as logging in only seems
> to work properly when you explicitly perform the --login action. It
> doesn't matter much for us but I'll file a bug about this later. For
> our users, I will add a pkg_config to the lgogdownloader package. The
> session lasts for a year so it's not like users will need to do this
> often.
>
> pkg_config() {
> 	umask 002
> 	XDG_CONFIG_HOME=/etc lgogdownloader --respect-umask --login
> }
>
> The only questions I have right now relate to Paludis. I've never used
> it and don't intend to but I want to try and do the right thing. Does
> it use the portage group to write distfiles? If not, does anyone have
> an idea for how I could handle this more portably, given that I'm
> creating /etc/lgogdownloader with root:portage? I'm also looking for a
> Paludis guinea pig.
>
> Other than that, I'm just looking for feedback. Please be kind. This is
> very much opt-in via the gogdownloader flag so if you don't have any
> major technical qualms with it, don't spoil the fun. :)
>
> Cheers,
>
I like this idea, and I would probably consider buying more games for
GNU/Linux if Portage had better support for it and/or if we could agree
on the way to build game ebuilds.

I have a few games from Humble Bundle that I'm looking to package
(Rocketbirds, A Virus Named Tom, and Wizorb), but the drama with games
team vs QA makes me question whether I should bother, because there
isn't a suitable document that outlines how we should package games. "Do
it like any other package" isn't good enough advice, because games are
often stored in /opt or some other location and have their own set of
problems like bundled-libs and so on.

None of this is aimed at you specifically, chewi. I think your idea here
is good and I'm sure the pickier people among us can find a good way to
make GOG games packageable while also retaining quality ebuilds. I would
join you in the games team if there were docs or guidelines, or even a
group of people who could give solid, _constructive_ criticism on game
ebuilds.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6