Bug#979592: RFS: openrct2/0.3.3+dfsg-1 [ITP] -- Open-source re-implementation of RollerCoaster Tycoon 2
Hi Mathias,
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.
>> I believe uploads to unstable are discouraged only for packages
>> already in testing, so targeting unstable here should be OK.
>
> OK, I've switched back to unstable and staged it locally. I'll bundle
> that with any other changes that come from the package review process
> before openrct2 gets uploaded to NEW.
Good, thanks.
>> 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?
> I personally use lxc containers which I can quickly spin up to get a
> clean minimal build environment, and the following commands build the
> openrct2 package for me:
>
> dget -x https://mentors.debian.net/debian/pool/main/o/openrct2/openrct2_0.3.3+dfsg-1.dsc
> dpkg-source -x openrct2_0.3.3+dfsg-1.dsc
> cd openrct2-0.3.3+dfsg/
> debuild
>
> I know there's several additional tools for building packages (like
> pbuilder), but I haven't really had a strong need to get those working
> due to my use of lxc.
I see. I have no knowledge about lxc builder, but somehow I imagine that
it should have the same build sequence.
Best,
Andrius
Reply to: