1 |
Hi guys, |
2 |
|
3 |
As the newest member of the games team, I've had a somewhat |
4 |
off-the-wall idea. Like many gamers, I have a sizeable collection of |
5 |
games purchased from GOG.com. There have been efforts to package some |
6 |
of these, mainly in overlays, and I'd like to see more in the tree. |
7 |
|
8 |
There are basically 3 methods for downloading their games. The first is |
9 |
manually from the web site. The second is via their Galaxy client, |
10 |
which is not yet available for Linux. The third is via their |
11 |
"gogdownloader" links, which were created for their older client. This |
12 |
client is no longer maintained but an open source alternative for Linux |
13 |
called LGOGDownloader is still active. |
14 |
|
15 |
GOG have not said that the gogdownloader links are going away. They |
16 |
have simply said that the API is subject to change, which suggests that |
17 |
they are also used by Galaxy. In any case, I'm sure that LGOGDownloader |
18 |
will adapt. |
19 |
|
20 |
So wouldn't it be great if Portage could handle these gogdownloader:// |
21 |
URLs? Before you throw your arms up at what appears to be proprietary |
22 |
nonsense, rest assured that this protocol is really just HTTP with |
23 |
authentication via OAuth. No doubt they chose their own scheme so that |
24 |
these links would fire up in their own client. This benefits us too as |
25 |
Portage uses the scheme to determine which fetch command to use. |
26 |
|
27 |
I recently added LGOGDownloader to the tree and some initial |
28 |
experiments with Portage have proved fruitful. Here are the key bits of |
29 |
an example ebuild. |
30 |
|
31 |
SRC_URI="gogdownloader://tomb_raider_1/en1installer1 -> setup_tomb_raider_${PV}.exe" |
32 |
IUSE="gogdownloader" |
33 |
RESTRICT="!gogdownloader? ( fetch ) mirror" |
34 |
DEPEND="games-util/lgogdownloader" |
35 |
|
36 |
pkg_nofetch() { |
37 |
einfo "Please purchase and download from GOG.com, etc…" |
38 |
} |
39 |
|
40 |
Some of this could go into a gog eclass. I've seen one in an overlay |
41 |
already. Ebuilds that support non-GOG sources could put this stuff |
42 |
behind a gog USE flag. |
43 |
|
44 |
I thought I would need pkg_pretend but I didn't realise that Portage |
45 |
attempts to fetch twice, once during the parallel fetch and again at |
46 |
build time if the first attempt fails. This means that even though you |
47 |
might not have lgogdownloader the first time, you will have it because |
48 |
of DEPEND the second time. |
49 |
|
50 |
The problem is that you will still have to configure Portage for this |
51 |
protocol manually unless it is added to the stock make.globals. Could |
52 |
this be done? If only everyone had make.conf as a directory then I |
53 |
could simply drop a file in there but even I don't. Paludis has the |
54 |
upper hand here as it supports several locations where you can drop |
55 |
"fetcher" configuration files. The configuration for Portage looks like |
56 |
this. |
57 |
|
58 |
FETCHCOMMAND_GOGDOWNLOADER="egogdownloader --output-file \"\${DISTDIR}/\${FILE}\" --download-file \"\${URI}\"" |
59 |
RESUMECOMMAND_GOGDOWNLOADER="egogdownloader --output-file \"\${DISTDIR}/\${FILE}\" --download-file \"\${URI}\"" |
60 |
|
61 |
egogdownloader is a small wrapper script that I have attached. It |
62 |
obviously simplifies what is needed above but also allows users to use |
63 |
the tool manually if they really want. |
64 |
|
65 |
lgogdownloader writes to ${XDG_CONFIG_HOME}/lgogdownloader and doesn't |
66 |
include a command line option to change this but we can obviously just |
67 |
set XDG_CONFIG_HOME to /etc. Portage already executes fetch commands |
68 |
with umask 002 but I added that for manual use. This ensures the |
69 |
configuration will always be writeable by those in the portage group. I |
70 |
had to write a patch (submitted, not yet in Portage) to add an option |
71 |
that prevents lgogdownloader from chmoding the sensitive files to 600. |
72 |
|
73 |
So what's the < /dev/null for? We don't want lgogdownloader to prompt |
74 |
for input and this effectively kills that. It normally prompts for your |
75 |
credentials if you're not already logged in or your session has |
76 |
expired. This behaviour actually seems broken as logging in only seems |
77 |
to work properly when you explicitly perform the --login action. It |
78 |
doesn't matter much for us but I'll file a bug about this later. For |
79 |
our users, I will add a pkg_config to the lgogdownloader package. The |
80 |
session lasts for a year so it's not like users will need to do this |
81 |
often. |
82 |
|
83 |
pkg_config() { |
84 |
umask 002 |
85 |
XDG_CONFIG_HOME=/etc lgogdownloader --respect-umask --login |
86 |
} |
87 |
|
88 |
The only questions I have right now relate to Paludis. I've never used |
89 |
it and don't intend to but I want to try and do the right thing. Does |
90 |
it use the portage group to write distfiles? If not, does anyone have |
91 |
an idea for how I could handle this more portably, given that I'm |
92 |
creating /etc/lgogdownloader with root:portage? I'm also looking for a |
93 |
Paludis guinea pig. |
94 |
|
95 |
Other than that, I'm just looking for feedback. Please be kind. This is |
96 |
very much opt-in via the gogdownloader flag so if you don't have any |
97 |
major technical qualms with it, don't spoil the fun. :) |
98 |
|
99 |
Cheers, |
100 |
-- |
101 |
James Le Cuirot (chewi) |
102 |
Gentoo Linux Developer |