Explicit versionsing of lix-music archive

[szpak]

Making a Lix package for Fedora, I've encounter one issues.

The music archive for Lix could be versioned. I realize that you might not plan to add extra file to it, but from the packager point of you an used file should be upstream immutable. On the other hand, I realize, that it is handy to have just one link to the latest version. Therefore, I propose to just add the extra link to lix-music-XX.zip (mentioned somewhere in the documentation for packagers) which will always point to the same version (the one valid as for 20230402) and lix-music.zip would internally just symlink to that file.
Once you modify something, then lix-music-YY.zip will be uploaded to the server, with a symlink lix-music.zip switched to the new file (the old one lix-music-XX.zip would stay as it untouched). WDYT?

[SimonN]

Hi! I'd prefer an extra git repository over having to keep multiple versions of the music zip file on my webspace. I can then tag the music repo, and github will create versioned zip files from the tags.

I can perfectly live with a link (that always provides the newest version) that merely points to a download page (e.g., the github tag page) and have that page automatically offer the newest versioned zip archive. That would be sufficient for Lix's main menu; it tells the player where to download the music. Or do you see another need for a symlink on the webserver?

I'll sleep over whether I'd like add such a new music repo as a subrepository of the main Lix repo.

---

It's also possible to put the music files directly into the main Lix repo, but I'm wary of growing the Lix repo too fat over time.

There is already a difference between the tracks in lix-music.zip and the tracks in my own Lix binary releases: For Lix 0.10.6 from 2023-02-04, the binary releases changed music/minim-mobius/meadow-sunrise.ogg: Removed wrongly looped initial segment. Before, the song started, then restarted after 2 seconds.

[szpak]

Probably keeping the music files outside the main repo is a good idea. Having a separate one for music sounds good to me - as you noted, it makes it easier to manage changes and do the "releases".

Having it (additionally) "mounted" as a submodule in the main one also looks ok - people might skip it if needed, the binary releases also can be done independently.

Update. I originally proposed a symlink as the (probably) least intrusive to the current distribution model. The Git approach is a way better for the aforementioned reasons (of course, you still can link in your game domain "to keep the old link(s) correct").

[SimonN]

I've reuploaded the music archive, fixing the beginning of meadow-sunrise.ogg. I.e., I've done exactly what you warn against: Push a new version with the same download link as the previous version (which I overwrote).

If new music ever comes around or if there are bigger changes, I'll prioritize this issue (explicit versioning of the music).

[Mailaender]

I've done exactly what you warn against: Push a new version with the same download link as the previous version (which I overwrote).

Undo that and create a version 1.1.zip for that.

[Lucki]

lix-music-1.zip

[SimonN]

^ Lucki attached the 1.0 archive. This is the exact file that @Mailaender had previously pinned in Flatpak. It has a sha256 of 8ae2323995ac8792f720e80130220a0e85da32269e25e5b9add8c586c16ef392.

If it's such a vital file, I'd prefer not to host it on lixgame.com with packages relying on it. Hosting the music on lixgame.com was a hack in the first place. :-)

I'll figure something out for immutable hosting of the music. Most likely, I'll make a github repo (or Codeberg or Sourcehut, as appropriate for FOSS?) and add the 1.0 and 1.1 archives as binary releases.

[Rhys-T]

FWIW this also came up when I was packaging it for Nix, since being reproducible/deterministic is kinda Nix's whole Thing and it won't let you download anything without telling it what hash to expect. I initially worked around it by linking to a snapshot of the file on web.archive.org. When that was down for a while, I added my own reupload as a mirror. I also added a fallback to extract the music from the Lix binary release archive. (The way I have the derivation coded, the hash is taken after extracting the archive and running my postFetch command, so I can get away with using a different archive as long as the files look the same when I'm done.)

[SimonN]

Yeah, if package managers require a checksum, the release strategy for the music fails where I offer only a single link to a latest version. The idea was: The exact choice of music is irrelevant; Lix will take any collection of music files and play randomly.

Instead, I should offer a link to the latest version and also permalinks to specific versions.

Theoretically, it's not guaranteed that all future versions of Lix will work with any random collection of music files; there could be, e.g., levels that want specific music. Also, theoretically, there could be malicious code in the executable that triggers only if specific music exists. Both are reasons to pin music versions.