legends-of-equestria: init at 2024.05.01

[UlyssesZh]

Description of changes

Added the game Legends of Equestria, a free-to-play MMORPG. I only packaged it for linux-x86_64. The developer distributed the game for darwin-x86_64 and darwin-aarch64 as well, but I do not have a macOS device to test.

Closes #289692.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[hugolgst]

Result of nixpkgs-review pr 296316 run on x86_64-darwin 1

[UlyssesZh]

@hugolgst I did not add darwin to supported platforms because the build process would be totally different from that on linux.

[hugolgst]

sorry mb didn't pay enough attention before running review

[GGG-KILLER]

Result of nixpkgs-review pr 296316 run on x86_64-linux 1

1 package built:

• legends-of-equestria

[GGG-KILLER]

It seems to work but I'm not sure what our precedent for having packages downloaded from MEGA is, even more so considering their bandwidth limits.

I'd be more comfortable with a webarchive link or some other source.

[UlyssesZh]

I can upload the file to archive.org and use that link instead, but that would make it difficult to have a working update script because uploading files to archive.org requires credentials.

[GGG-KILLER]

I can upload the file to archive.org and use that link instead, but that would make it difficult to have a working update script because uploading files to archive.org requires credentials.

Yes, however downloading from mega makes it unfeasible for a lot of people to use if they've already hit the MEGA bandwidth limit, which in turn would prevent them from using this package.

Uploading the file to a web archive is usually the standard procedure from what I know.

An update script is nice, but that isn't very helpful if a lot of people are unable to use the package.

[UlyssesZh]

I see the problem here. It is indeed correct that people that hit the free download quota will be unable to download the file (MEGA checks the quota based on the client's public IP address). However, I don't think the problem would appear on the end users' side. For people that are unable to download files from MEGA, they would not be able to download the software anyway with nixpkgs or not. This is because MEGA is the only official source of the software. For those who have a paid plan of MEGA and cannot download the file without their credentials, I think I may add somewhere for them to enter their MEGA credentials via override. Also, the free download quota of MEGA counts on a daily basis anyway, so they can just try downloading it again on the next day.

Where the problems may really appear is on continuous integration systems such as those of nixpkgs. The problem is currently unimportant because this is the first package that uses MEGA as a source. In the future, if there are many packages that require files from MEGA, a continuous integration system can easily hit the free download quota if it tries to download many large files from MEGA behind the same IP address. I think this issue needs more discussing.

Now, on using archive.org. I don't know whether it is appropriate to distribute an unfree software using a download link that is totally irrelevant to the official source. Most of the existing usage of archive.org in nixpkgs, as I see, is just a web archive for the official download link. This could be considered still an almost-official source because people generally agree that web archives on archive.org reliably save the same thing as what the web contents were originally. However, this consensus does not exist for user-uploaded contents on archive.org. A more acceptable alternative that I can think of is that I can put an archive.org link in the comment of the package for those who cannot download the necessary file from MEGA. They can manually download and extract the file and use a nix-store command to manually add it to nix store so that nix would not try to download from MEGA when building the package.

Then, on the update script. I admit that, for most cases, having an update script is not better than having a bunch of people not being able to use the package. However, I think this package can be considered a special case because it is an online game. It is important to keep an online game up-to-date because people cannot log in the game without an up-to-date client (at least this is the case for LoE). If they cannot log in, the package is just not different from being unusable. On the other hand, as I already argued, being unable to download files from MEGA is not quite a big problem for end users, so this does not make it preferable to sacrifice the update script.

Upon some additional thoughts, though, I think it is still possible to have an update script if I finally decide to use an archive.org link as the source. I may develop a GitHub action that periodically checks for updates. If there is an update, download the file using my MEGA credentials and upload the files to archive.org using my credentials. In the update script, read the result of the GitHub action. There are two issues that I may have to look up for this approach to work. The first is how large files can a GitHub action download and upload. The second is what is the appropriate way of reading GitHub action results in the update script (almost all the GitHub REST APIs require a token, but I surely cannot put my token in the update script).

[UlyssesZh]

I am trying to package for darwin, but the problem is that megacmd is not packaged for darwin. I tried to package that, but I failed with strange problems. I requested for its darwin support in #297586.