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
