search

Naxesss / MapsetVerifier

A modding tool for osu!
93 stars 8 forks source link

Linux Compability #6

Open rorre opened 4 years ago

rorre commented 4 years ago

Here are some issues found out during testing on Linux.
OS: Manjaro Linux

For last point, it seems to be caused by the fact that MapsetVerifierBackend is not consistent with Mapset Verifier's appdataPath.

On MVBackend, it uses Environment.SpecialFolder.ApplicationData that points out to ~/.config, while Environment.SpecialFolder.LocalApplicationData points out to ~/.local/share[1]

[1] https://jimrich.sk/environment-specialfolder-on-windows-linux-and-os-x/

Naxesss commented 4 years ago

Think the reason resources/app-update.yml and lastest-linux.yml are missing is because of "target": "tar.gz" in the package step. According to Auto-updatable Targets, only AppImage will work for this.

Is the first point about updates not being automatically downloaded/installed (after a newer version is found), or that no new version can be found when there actually is one?

rorre commented 4 years ago

It wouldn't even bother looking at it because the config of the updater itself (app-update.yml) is missing.

Checking for update
Error: Error: ENOENT: no such file or directory, open '/home/rorre/mapsetverifier/resources/app-update.yml'
    at /home/rorre/mapsetverifier/resources/app/node_modules/electron-updater/src/AppUpdater.ts:459:27
    at Generator.next (<anonymous>)
Naxesss commented 4 years ago

Update: We've tested a few things and found that targeting AppImage produces an app-update.yml file when built on linux, but when built on windows seems to run into the problem described in this issue.

Kyuunex commented 2 years ago

Ah this issue is a thing. Not really a problem per say but it would really be nice if you could put the source code of the project into the repo itself, and make releases that snapshot the code. And also do releases for backend's repo too that correlate the same version number with the electron frontend. I am thinking of making a non -bin package on the AUR that build the software on the user's computer from the source code. Right now, I have to do weirds things for the -bin package to work like change the working directory with a launcher script which is not really an issue but really a "hacky" solution. A proper solution would be having patches (in the AUR repo) that hardcode paths (which is how things usually happen when packaging for linux) and it will greatly aid in that. I could make the builder script download the prebuilt package to just get the source code but it will be a waste of bandwidth.

Kyuunex commented 2 years ago

Another issue I am trying to solve by moving to the user building the package instead of a -bin prebuilt is, using a system (global) install of electron. This is common for OSS software that is packaged on Linux. A benefit to this approach is, receiveing security fixes related to electron, straight from the electron package maintainer.

Naxesss commented 2 years ago

Having divided up components into their own repositories makes including all source code here a bit difficult. Submodules don't work particularly well either. If I were to remake it all I'd likely prefer putting it in the same repository.

I could probably make a workflow that creates releases of each component and then assembles them into a release in this repository, all with the same version numbers. That way, ...

Kyuunex commented 2 years ago

Either way, the first step would be just having the source code in any repo in the first place. I said what I said because I noticed you already have the backend source code in a different repo, but the electron project sources are not in any repo at all. Organize the sources in any repo however you want, as long as they are there. That will also allow others to send pull requests, which I am willing to do to fix anything Linux related.

Naxesss commented 2 years ago

Ah I see, you mean the files I use to build the electron app, including the frontend code. I'll likely try the workflow project thing in conjunction with a new repo for that. Making releases is getting more and more painful as I forget the small intricacies of the process, so having it all deploy automatically seems pretty necessary.

Though this'll have to be a future project; not quite ready to delve into this stuff yet.