Arch Linux User Repository

@proledatarian and @sukanka, i agree with you both @taotieren ver 1.2.2-3 is working now, thanks

arch= has to be specified and can not be empty or missing.

And if I add arch= it's still broken.

error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: rustdesk-bin and rustdesk-appimage are in conflict

I'd prefer rustdesk-appimage to be a separate package, instead of a split package.

I only use the -bin package, and don't want these appimages to be downloaded, especially the aarch64 one, as my arch is x86_64. (I cannot understand why an arch user would like to use an appimage since it can be re-packaged to an ordinary -bin package.)

The package assembly broke down:

rustdesk-bin: No arch field
goroutine 1 [running]:
runtime/debug.Stack()
    runtime/debug/stack.go:24 +0x5e
runtime/debug.PrintStack()
    runtime/debug/stack.go:16 +0x13
main.main.func2()
    github.com/Jguer/yay/v12/main.go:155 +0x58
panic({0x555a5995e660?, 0xc00026b660?})
    runtime/panic.go:914 +0x21f
github.com/Jguer/yay/v12/pkg/srcinfo.NewService({0x555a599dc988?, 0xc0002461b0}, 0xc00023e000, {0x555a599da458?, 0xc000226600}, {0x555a599d9110?, 0xc000224280}, 0xc0003ac270)
    github.com/Jguer/yay/v12/pkg/srcinfo/service.go:37 +0x13f
main.(*OperationService).Run(0xc0003ac060, {0x555a599d86c8?, 0x555a59c8e420}, 0xc000238120, {0xc0003c0000, 0x1, 0x1}, {0x555a59c8e420, 0x0, 0x0})
    github.com/Jguer/yay/v12/sync.go:142 +0xb96
main.syncInstall({0x555a599d86c8?, 0x555a59c8e420}, 0xc00023e000, 0xc000238120, {0x555a599dc988, 0xc0002461b0})
    github.com/Jguer/yay/v12/sync.go:91 +0xe77
main.handleSync({0x555a599d86c8, 0x555a59c8e420}, 0xc00023e000, 0xc000238120, {0x555a599dc988, 0xc0002461b0})
    github.com/Jguer/yay/v12/cmd.go:366 +0x8eb
main.handleCmd({0x555a599d86c8, 0x555a59c8e420}, 0xc00023e000, 0xc000238120, {0x555a599dc988?, 0xc0002461b0?})
    github.com/Jguer/yay/v12/cmd.go:176 +0x345
main.main()
    github.com/Jguer/yay/v12/main.go:161 +0x985

@kuhtoxo 1. Architectural issues have been revised

1. Regarding the problem of slow download, if you are in China, you need to manually add ghproxy.com for proxy acceleration or other ways to solve the problem by yourself.

2. if you want to maintain the rustdesk-appimage package, I can add you as a co-maintainer to maintain the package.

3. Regarding the issue of skipping checksums, the packages in the upstream repositories are updated frequently, so update them yourself if you need to.

In the official repository https://github.com/rustdesk/rustdesk/releases / for the current version, there is pkg.tar.zst just for x86_64, and there is no such package for aarch64, although both architectures are specified in PKGBUILD rustdesk-bin. There is a rustdesk-appimage for which there are x86_64 and aarch64 official builds. I think that in PKGBUILD rustdesk-bin should be specified only officially supported architecture x86_64 for aarch64 you need to use rustdesk-appimage.

In PKGBUILD rustdesk-bin, both pkg.tar.zst and appimage rustdesk are downloaded during assembly and installation, which takes quite a lot of time on a slow connection and is as impractical as possible, and therefore I think that appimage should exist only in the rustdesk-appimage package, and in rustdesk-bin only pkg.tar.zst should be downloaded.

I think PKGBUILD rustdesk-bin should match PKGBUILD of the official package as much as possible.

The use of SKIP is not recommended for calculating checksums of the downloaded package, because this can lead to unforeseen consequences on unreliable or untrusted connections, although it complicates package support.

pkgrel should be beginn with 1 not with 0. please follow the conventions ;-)

Hi, checksum fail. For me the correct one is:

475271880d3f78bcd571b6c2d382f855c8451f41cba992a51ac9fd7e7c9d84e2 rustdesk-1.2.2-0-x86_64.pkg.tar.zst

Hey, sorry, but I won't maintain this package anymore.

I stopped using it, because the codebase is incredibly bad to the point where I wonder how it's even functional.

Just have a look at this file for example: https://github.com/rustdesk/rustdesk/blob/master/src/platform/linux.rs
All paths are formatted with format!(), while rust has a builtin cross-platform solution for paths, which would probably also save them a lot of duplicate code. Furthermore, a lot of functionality is accomplished by executing shell commands, and piping the result into other shell commands, which is just bad style. What if one of these shell commands isn't installed on a system?

Also a lot of edge-cases seem to be unhandled:

https://github.com/rustdesk/rustdesk/blob/5875cb1896936ddff47e3931ac11e6ab37ce1036/src/platform/linux.rs#L1180
What happens if $HOME is unset? Ah yes, of course it tries to create the file /.config/autostart/rustdesk.desktop.

https://github.com/rustdesk/rustdesk/blob/5875cb1896936ddff47e3931ac11e6ab37ce1036/src/platform/linux.rs#L671
If you cancel the pkexec prompt, rustdesk thinks you have super-user permissions, because pkexec then exits with 127 instead of 126.

These are just a few examples I found without much effort in a few minutes. You might argue that these aren't critical issues, and I agree. But if all of their code is written in a similar fashion, it will almost certainly also contain a lot of actual security issues.

But the worst thing about rustdesk is their lack of respect for the users (or the users system). Since version 1.2.0, rustdesk always creates an autostart entry, forcing you into workarounds like modifying the autostart entry to avoid autostarting it. When I reported this issue, they just closed it as wontfix, without any explanation: https://github.com/rustdesk/rustdesk/issues/4863

And they have done similar things in the past, where they changed your gdm configuration and disabled wayland with a simple click on a button that said "Fix it!", with no explanation on what it's going to do: https://github.com/rustdesk/rustdesk/blob/1.1.9/src/platform/linux.rs#L411-L422

Their code quality has also been critized in the past:
https://news.ycombinator.com/item?id=34723752
https://news.ycombinator.com/item?id=34723595

So that's definitely enough reason for me to not trust the authors of this software. You're free to keep using this software, but I didn't want to just stop maintaining this package without stating my reasons. If anyone wants to co-maintain this package you can give taotieren a ping.

@Marzal: Thanks, added!