[Bug]: Automatic updater gets run on Linux

[kyngs]

Preflight checklist

• I have searched the issue tracker for a bug report that matches the one I want to file, without success.
• I have searched the frequently asked questions for a solution that fixes this problem, without success.
• I have checked that I'm using the latest stable version of the app.

What app version are you using?

v4.2.7

What operating system version are you using?

Linux

Expected Behavior

Miru lets the system package manager handle the updating.

Actual Behavior

Miru automatically tries to update. Since most if not all Linux installations are done through the package manager, this could cause conflicts when the package manager tries to update Miru. An alternate solution would be to include some file in a specific location, indicating that a package manager manages the current Miru installation.

Also, does the updater also run on dev builds? This could be unintended too.

Screenshots

No response

[kyngs]

Oh also the notification seems to get run several times per session

[ThaUnknown]

it should be miru that updates the package not the package manager, this isn't something I'm willing to support or change, use AUR if this is a problem

[kyngs]

use AUR if this is a problem

Yes, this is a problem because I use AUR. Lemme tell you my situation:

• I install Miru from AUR version 4.2.7
• I perform system-wide upgrades (which also upgrade Miru to the latest version) a few times a week.
• I start Miru and it says it updated to version 4.2.8 and I need to restart for the changes to apply
• I restart Miru and see that the updater did not update (apparently does not work on Linux at all, possibly due to missing permissions to edit the binaries. If it was the case, it would not be easily fixable and would require running Miru under root which is a horrible security risk I'm not willing to accept) and it is still running on 4.2.7 (Tho, the updater tells me the previous step every time I use Miru)
• I perform a system-wide upgrade and the package manager pulls the latest build from AUR and upgrades Miru to the latest version
• This cycle repeats when Miru pushes an upgrade before I do one on my PC

Even if the built-in updater worked, it would not make sense to self-update it, because the system package manager would not detect it (because in its index Miru is still on an older version), and still would upgrade Miru to the latest version anyway.

My proposed solution is either:

• Just not run the updater on Linux (because it also appears to be broken)
• Or, if the file permissions were the case for the updater to not work, and you would want to support people who did the manual installation of Miru (and should have the Miru installed in their home folder, to which Miru has full access), I could edit the AUR package script (I currently only have access to miru-git, but I could contact the maintainer of miru) to add a file into Miru's install directory (I believe it's /opt/miru) which would indicate that the current Miru installation is managed by the system and thus should not be updated by Miru itself.

If you still decide not to support it, I will just probably maintain a fork with Linux compatibility patches.

[ThaUnknown]

i still dont understand the issue here, the auto-updater simply doesnt work, so it doesnt matter that it doesnt work? and aur simply will update it regardless?

@Muril-o is this actually an issue?

I'm not turning off the auto updater, and I'm not even willing to provide code for it, it exists for a very very very valid reason, and updates are forced for the same very very very valid reason. Im a solo dev so it often happens that I push broken versions, forced auto-updates are mandatory

[kyngs]

it doesnt matter that it doesnt work? and aur simply will update it regardless?

Yes, but I constantly get bombarded with the please restart miru notifications.

[ThaUnknown]

electron bug, not miru bug

[ghost]

i still dont understand the issue here, the auto-updater simply doesnt work, so it doesnt matter that it doesnt work? and aur simply will update it regardless?

Regarding the auto-update feature itself, this is the intended behavior, the auto-updater does not and should not work by itself on GNU/Linux. I'm strongly against applications, installed through a package manager (or AUR helpers in this case), managing their own versions.
If they want this they can just install the AppImage as a normal user (not through the package manager) and it will update itself on restart, just like on windows.

But this is not the issue @kyngs is describing. As far as I understood, they're fine with being behind a couple versions (because they don't want to run the package manager update all the time), but they don't want the constantly 20 mins update reminders.

This is not an issue that existed before, this is actually electron-related. From the electron documentation:

Platform Notices
Currently, only macOS and Windows are supported. There is no built-in support for auto-updater on Linux, so it is recommended to use the distribution's package manager to update your app.

Turns out there's now a built-in support for auto-updater on GNU/Linux since the 4.2.3 electron version bump.
While I'd like to fix it, as you can see from the above referenced documentation the feature is still undocumented, so I'd have to look into the actual implementation to see if there are any electron native workarounds like if they added a flag that comes with the event emitter response. I believe this would be the best solution as this bug wasn't something that existed before, but was caused by electron's implementation.

but I could contact the maintainer of miru

Hello, that's me, I'd in fact appreciate help on maintaining the AUR package as I'm on Guix now and been slowly migrating away from Artix (my previous distribution). I feel like I don't have enough time to keep up with Miru's frequent updates, so a little bit of help would be appreciated.
We could think of some solutions for the AUR package itself, but I'd prefer to look for a native way of handling it with electron for the reasons I explained above.

[kyngs]

Regarding the auto-update feature itself, this is the intended behavior, the auto-updater does not and should not work by itself on GNU/Linux. I'm strongly against applications, installed through a package manager (or AUR helpers in this case), managing their own versions.

I absolutely agree with this. On Linux, programs should be managed by the system.

If they want this they can just install the AppImage as a normal user (not through the package manager) and it will update itself on restart, just like on windows

That's ideal, how does the script detect whether it's running from an AppImage? Is it from some environment var?

Hello, that's me, I'd in fact appreciate help on maintaining the AUR package as I'm on Guix now and been slowly migrating away from Artix (my previous distribution). I feel like I don't have enough time to keep up with Miru's frequent updates, so a little bit of help would be appreciated.

I personally use the miru-git package, however, in your package, maintaining it should only require bumping the version.

[ghost]

That's ideal, how does the script detect whether it's running from an AppImage? Is it from some environment var?

Need testing but I believe its an env var called APPIMAGE, since before the bump we had this warning:
[warn] APPIMAGE env is not defined, current application is not an AppImage.
updatable-targets
Not sure if it works on latest electron because again there's no documentation on it, and not really useful to set now since all linux targets seem to auto-update regardless of target.

[EnergoStalin]

electron bug, not miru bug

Looks like it resolved in electron-updater@6.1.3 for some subset of distros. Can confirm it's not erroring now but updater still unusable on arch tested on it's latest release @6.1.5.

19:11:04.338 › Executing: which gksudo || which kdesudo || which pkexec || which beesu with args: 
19:11:04.349 › Executing: /usr/bin/pkexec --disable-internal-agent with args: /bin/bash,-c,'dpkg -i /home/alexv/.cache/miru-updater/pending/linux-Miru-4.4.12.deb || apt-get install -f -y'

Sweet message when installing dpkg i almost done mistake thanks for warning pacman. Look's like electron-updater can break arch)

(1/1) installing dpkg                                                                                                                                                                                                            
    dpkg installs Debian package manager.
    This is useful for those who want to create/modify DEB files.
    However, *do not* use dpkg to install Debian packages in your ArchLinux machine.
    This will break your system!
    You will need to go back to Arch wiki and read the installation guide again.
    You've been warned!

Guess we can't avoid workarounds on arch. The most easiest would be add flag to disable updater on unsupported platforms keeping it running by default. I asked a question on electron-builder let's see what community think.

[ThaUnknown]

has electron fixed this yet?

[EnergoStalin]

It's working as I said. Would work anywhere where dpkg can be used to manage dependencies. But not for arch according dpkg install warning.

I think we can try implementing update mechanism by yourself through cloning miru-bin aur package into tmp folder and then replacing version and checksum in PKGBUILD file running makepkg -si afterwards. If forcing updates is truly needed. I think everyone would be happy this way. Can do a PR if you agree with that. Don't think electron can do much with it because you need to have package on aur or built it into miru itself to do that. Can be considered but implementing this in miru side seems faster than waiting upstream. Through contributing this in electron-updater can be considered separately.

[kyngs]

It's working as I said. Would work anywhere where dpkg can be used to manage dependencies. But not for arch according dpkg install warning.

I think we can try implementing update mechanism by yourself through cloning miru in tmp folder and then replacing version with sum in PKGBUILD file running makepkg -si afterwards. If forcing updates is truly needed. I think everyone would be happy this way. Can do a PR if you agree with that. Don't think electron can do much with it because you need to have package on aur or built it in into miru itself to do that. Can be considered but implementing this in miru side seems faster than waiting upstream. Through contributing this in electron-updater can be considered separately.

This would assume that the package would be updated instantly when a miru update releases. Otherwise the auto updater would get stuck in an endless loop of updating miru. Forcing updates is simply a bad idea and should be scrapped. Also, this would require miru to have root access, which simply sucks too.

[EnergoStalin]

It won't assume it will be cloned and updated by hand written updater module automatically. Because current way @Muril-o handling install requires only bumping a version and changing checksum in PKGBUILD. Which I currently doing manually to update because obviously he can't catch up with updates instantly.

[kyngs]

How exactly has this been resolved?

[ThaUnknown]

electron-updater now properly supports .appimage and .deb files, which i distribute via releases, and for now those are the only official ways of installing miru, the "but flatpak and aur updates" is an issue addressed to their maintainers not to me tbh

[beeble-wonjunyoon]

@ThaUnknown, thanks for your assistance! I've discovered that auto-update functions correctly with both .appimage and .deb formats. However, I'm encountering issues with the .rpm file. When a new version is available, it gets downloaded, but it doesn't seem to install correctly. As a result, the application restarts using the old version and notifies me that a new version has been downloaded again and again. Any suggestions will be really appreciated.

[kyngs]

@ThaUnknown, thanks for your assistance! I've discovered that auto-update functions correctly with both .appimage and .deb formats. However, I'm encountering issues with the .rpm file. When a new version is available, it gets downloaded, but it doesn't seem to install correctly. As a result, the application restarts using the old version and notifies me that a new version has been downloaded again and again. Any suggestions will be really appreciated.

That goes the same for Arch. Afaik, he said that only .Deb and appimage is officially supported. I've resolved this by forking the program and just yeeting the auto updater

[sweetbbak]

probably should just drop the AUR package from the README since its out of date at version 4.5.9-1 and just outright say you support only the .deb and .AppImage which is more than enough. There is also a flatpak package that is well-maintained. There is definitely a bug when A) Miru is out of date and B) when Miru is not on the target platform.

The AppImage updater works fine when the download method is using the AppImage, but outside of that it automatically assumes the platform is Debian/Ubuntu and does what I mentioned in my issue. I'd be happy to send a PR to just fix this

[EnergoStalin]

Let's just imagine for a second that core problem is aur package outdated most of the time... I tried to contact with it's maintainer which i belive is @Muril-o through email and suggest doing simple github actions thing for that.

The flow is following

Miru CI(deploy new version & trigger external workflow in miru-bin) -> miru-bin CI(updates it's sha hash and version from workflow_dispatch args commiting to itself and pushing to aur)

That way aur package keeps separated and updated straight up on miru release by webhook without any human interaction.