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,
--
James Le Cuirot (chewi)
Gentoo Linux Developer
#!/bin/sh
: ${DISTDIR:=$(portageq distdir 2>/dev/null)}
: ${DISTDIR:=/usr/portage/distfiles}
umask 002
XDG_CONFIG_HOME=/etc lgogdownloader --respect-umask --no-subdirectories
--directory "${DISTDIR}" "${@}" < /dev/null
RET=$?
if [ "${RET}" != 0 ]; then
echo -e "\nIf authentication failed, try logging into GOG.com again
with:\nemerge --config lgogdownloader\n" >&2
fi
exit "${RET}"
