On Tue, 2021-03-16 at 12:57 +0200, Andrius Merkys wrote:
> 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.
Yes, by default openrct2 places all config, save games, objects, etc
in ~/.config/OpenRCT2/. It also respects the XDG_CONFIG_HOME
environment variable.
>
> > > 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?
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 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 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
>
Thanks for helping me build a better package(s)!
Mathias
Attachment:
signature.asc
Description: This is a digitally signed message part