On Tue, 25 Jul 2017 at 20:47:01 +0200, Johannes Schauer wrote: > Quoting Simon McVittie (2017-07-25 09:01:45) > > If there are files in "$dest_dir" that are edited at runtime, we will also > > need to know which ones (compare the clean "$dest_dir" with the one you > > moved > > out of the way). If there are files that you know are not strictly required > > (the music?) we would also like to know about those. > > I understand that g-d-p does not want to package files that are not needed at > all but why does it need to know about optional "nice to have" files as well?
Sorry, I might have been unclear. The piece of information we really want is: of the files you listed, which ones do you know to be optional? g-d-p is aware of four categories of files: known and required; known and optional; known and unwanted (rare, mostly only used for known-to-be-obsolete versions of data files); and unknown/unwanted (it will issue a warning if the unknown file resembles a known file but doesn't match exactly, on the assumption that it might be a new version that we need to be told about). If a required file is missing, g-d-p will fail to create a package (but it might automatically package a demo/shareware/cut-down version instead, and it might still package the base game if the file was only required for an expansion like Quake III Team Arena). If an optional file is missing, g-d-p will still create the package (with less content!) - we are not dogmatic about these packages being deterministic, because that's a losing battle when some games have trivially-different versions of the same file, like the subtle differences between different releases of Unreal and the many equivalent versions of Doom. Typically, optional files are used for things like READMEs and licenses, which might be different or absent in some releases. If an identifiable group of files are all optional (like maybe the music in HoMM3) we tend to split it out into an "expansion" package, which is a separate binary package. Each YAML file in data/ is analogous to a dpkg source package, and can produce multiple binary packages if it needs to. > > If there are several alternative versions of HoMM3, we will need similar > > information for each one. If you have the GOG version but not the CD > > version, > > or vice versa, then different people can submit the two sets of sizes and > > hashes. > > I own it on GOG and I have the CD version. But since the CD version is with my > parents it will have to wait until I visit them again. There's no urgency, but when you get a chance, it would be nice to confirm what's in it. > vcmi is already able to decode the original mp3 just fine. Converting the > audio > with the vcmibuilder script is also completely optional. Then I think it'll keep things simple for g-d-p to be completely unaware of the Vorbis versions, and have the MP3s in its data (flagged as optional or separated into a heroes3-music package if desired). > > Finally, vcmibuilder puts the data files in ~/.local/share/vcmi, but > > game-data-packager produces .deb files which need to install in /usr. If > > vcmi > > follows the XDG Base Directory specification correctly, it should also > > recognise these files in /usr/share/vcmi. > > There is an upstream bug about it http://bugs.vcmi.eu/view.php?id=2189 and a > bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783030 Ah, I see it already looks in /usr/share/vcmi (which we can work with) but Alexandre would prefer /usr/share/games/vcmi. I'm personally less convinced by the usefulness of the /usr/share{,/games} split than Alexandre is, but I can see the reasoning for wanting to separate it. I'm a little surprised vcmi doesn't have an equivalent of the Quake engine's -basedir option. That would perhaps be useful if you want to support side-by-side installation of the demo and the full game. S