Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
On 2021-03-23 02:08, Mathias Gibbens wrote:
> On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote:
>> On 2021-03-15 19:28, Mathias Gibbens wrote:
>>>> I have reviewed your packaging, and saw libcurl4-openssl-dev
>>>> among
>>>> the build dependencies. Do you know what does openrct2 need it
>>>> for?
>>>> My concern here is that in-game network access/downloads may
>>>> interfere with Debian policies.
>>>
>>> Grepping through the code, it appears that openrct2 uses the
>>> libcurl
>>> dependency primarily in two places. The first is to automatically
>>> download missing objects referenced in a scenario or save game.
>>> There's
>>> a vibrant community of openrct2 fans who create custom scenery
>>> objects,
>>> and it looks like this is a helper to fetch missing custom objects.
>>> I've not gotten into this aspect of the game, so I haven't
>>> personally
>>> used it. The second place libcurl is used is in support of
>>> multiplayer
>>> connection making.
>>>
>>> Both of these only happen when the end-user is running the
>>> program,
>>> so I think that shouldn't run afoul of Policy. (I know network
>>> access
>>> during build is verboten, which is why there's an
>>> override_dh_auto_configure in d/rules and corresponding component
>>> source tars [more below].)
>>
>> Thanks for checking this out. Both use cases are indeed not violating
>> the policy.
>>
>> However, we need to make sure the downloader for missing objects
>> knows
>> the right place to put them. It must not attempt writing outside
>> user's
>> home directory.
>
> Yes, by default openrct2 places all config, save games, objects, etc
> in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME
> environment variable.
Good then. Thanks for confirming.
>>>> I fail to build the package as of
>>>> e6e4103971b570a179ef5a59a709c24b2fcc5d68 on clean sid chroot with
>>>> the
>>>> following error log (only the last lines):
>>>>
>>>> [snip]
>>>>
>>>> Any ideas what might have gone wrong?
>>>
>>> This is the first package I've created that contains multiple
>>> upstream tarballs as described in uscan(1). The normal openrct2
>>> build
>>> downloads a handful of pre-generated metadata (the "objects"
>>> component
>>> tarball) and custom scenarios for the opening sequence (the "title-
>>> sequences" component tarball) at build time, but we can't do that
>>> in
>>> Debian. So I added them as additional sources. The error you're
>>> seeing
>>> indicates that for some reason they aren't being properly extracted
>>> into the source directory prior to starting the build.
>>
>> Indeed, this must be the problem on my side, due to incorrectly
>> created
>> upstream tarball. I admit I know very little about multiple upstream
>> tarballs (MUTs).
>>
>> However, in this case it looks like the split of the MUT to
>> individual
>> source packages would make sense. They seem to have version numbers
>> on
>> their own, and I notice no signs in them being released in a
>> lockstep.
>> For example, it might happen that at some point objects or
>> title-sequences are released more often that the main game, and
>> bumping
>> Debian version of the MUT just to update the components will become
>> tedious. What do you think about splitting?
>
> It would certainly be easy enough to split the components out into
> three distinct source packages:
>
> openrct2
> openrct2-objects
> openrct2-title-sequences
>
> And then have openrct2 depend on the other two to properly bring in
> all the required bits of the program.
I would suggest exactly the same.
> I set things up using MUTs to try to reflect upstream's build process
> as closely as possible, but as you point out having three distinct
> packages will allow more flexibility when updating in the future.
>
> My only question would be if having three different packages would
> make the RFS process any harder, and if I should then file two more RFS
> bugs for the two new source packages.
I do not think this would make RFS process any harder. As the releases
of these three packages do not happen in a lockstep, you would probably
want to upload the MUT whenever any of them is released anyway. MUT
might save extra RFSes in case of simultaneous release, but I do not
think this is worth optimizing for.
In practice, instead of filing RFSes I used to ping my initial
sponsor(s) with a list of packages I want to get uploaded. RFS is a
formal request, but I see people directly mailing packaging teams with
requests for uploads. And maybe at some point you will become a DD and
will be able to upload packages yourself.
> Thanks for helping me build a better package(s)!
Thank you for working on openrct!
Best wishes,
Andrius
Reply to: