starred/rustdesk-rustdesk

Fork 0

mirror of https://github.com/rustdesk/rustdesk.git synced 2026-03-02 19:26:56 -05:00

Add APT repository #586

New issue

Closed

opened 2026-02-20 23:05:44 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-20 23:05:44 -05:00

Owner

Originally created by @silopolis on GitHub (Jul 9, 2022).

Hi,

This great and so much needed piece of code deserves an APT repository to ease install and updates on Debian derivatives !

Thanks for all

TY
J

Originally created by @silopolis on GitHub (Jul 9, 2022). Hi, This great and so much needed piece of code deserves an APT repository to ease install and updates on Debian derivatives ! Thanks for all TY J

deekerman

2026-02-20 23:05:44 -05:00

closed this issue
added the
enhancement
label

deekerman commented

2026-02-20 23:05:48 -05:00

Author

Owner

@simeononsecurity commented on GitHub (Aug 8, 2022):

@silopolis I agree this would be nice, however if they did this, they would also have to implement repos for the other various OS'es. This would unfortunately require a fair bit of work to implement and eventually automate. However, I agree this should definitely happen at some point. However with the software in what I'd consider to be still beta, maybe even alpha, it's not the highest thing on the list.

@simeononsecurity commented on GitHub (Aug 8, 2022): @silopolis I agree this would be nice, however if they did this, they would also have to implement repos for the other various OS'es. This would unfortunately require a fair bit of work to implement and eventually automate. However, I agree this should definitely happen at some point. However with the software in what I'd consider to be still beta, maybe even alpha, it's not the highest thing on the list.

deekerman commented

2026-02-20 23:05:48 -05:00

Author

Owner

@Oceanwatcher commented on GitHub (Jan 17, 2023):

I second this. A Ubuntu repository would first of all make it really easy to install. Just do a sudo apt install rustdesk.

But it would also make it real easy to keep updated as you can set the system to do minor updates automatically. This improves the security and should count for a lot. Actually, the upgrade process today is not documented as far as I can see. It should be as easy as sudo apt update and sudo apt upgrade ;-)

I avoid docker as the plague and prefer to have a small VPS for the server instead. And these days you can set up a small VPS on Oracle for free. It will at least help with the testing.

And I completely disagree that it has do be done for all other OS'es as well. At least not from the start.Ubuntu is a solid, widely used OS and would be a natural place to start. If other OS'es has similar delivery methods, then yes, it should be natural to add them eventually. But at least getting one OS up and running with this will lower the threshold for people to set up their own relay server.

@Oceanwatcher commented on GitHub (Jan 17, 2023): I second this. A Ubuntu repository would first of all make it really easy to install. Just do a sudo apt install rustdesk. But it would also make it real easy to keep updated as you can set the system to do minor updates automatically. This improves the security and should count for a lot. Actually, the upgrade process today is not documented as far as I can see. It should be as easy as sudo apt update and sudo apt upgrade ;-) I avoid docker as the plague and prefer to have a small VPS for the server instead. And these days you can set up a small VPS on Oracle for free. It will at least help with the testing. And I completely disagree that it has do be done for all other OS'es as well. At least not from the start.Ubuntu is a solid, widely used OS and would be a natural place to start. If other OS'es has similar delivery methods, then yes, it should be natural to add them eventually. But at least getting one OS up and running with this will lower the threshold for people to set up their own relay server.

deekerman commented

2026-02-20 23:05:48 -05:00

Author

Owner

@hex-m commented on GitHub (Jan 18, 2023):

The most sustainable way to solve this would be to add rustdesk to the official repository of Debian. Ubuntu automatically gets packages that are in Debian (src).

Packages that have recently been added to Debian unstable will be automatically synced into Ubuntu

So the next step would be a Debian RFP.

@hex-m commented on GitHub (Jan 18, 2023): The most sustainable way to solve this would be to add rustdesk to the official repository of Debian. Ubuntu automatically gets packages that are in Debian ([src](https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages)). > Packages that have recently been added to Debian unstable will be automatically synced into Ubuntu So the next step would be a [Debian RFP](https://wiki.debian.org/RFP).

deekerman commented

2026-02-20 23:05:48 -05:00

Author

Owner

@lweberk commented on GitHub (Mar 31, 2023):

In the meantime I've been distributing it over a private repository, for which the problem becomes the versioning. Development versions (nightly) do not tag the dev portion (pre-release for ex.) in their release schema. It makes it really hard to propagate new versions this way, since there is nothing telling the packaging managers about the new nightly actually being newer than the one the day before.

I can imagine, this will also be a problem upstream.

@lweberk commented on GitHub (Mar 31, 2023): In the meantime I've been distributing it over a private repository, for which the problem becomes the versioning. Development versions (nightly) do not tag the dev portion (pre-release for ex.) in their release schema. It makes it really hard to propagate new versions this way, since there is nothing telling the packaging managers about the new nightly actually being newer than the one the day before. I can imagine, this will also be a problem upstream.

deekerman commented

2026-02-20 23:05:48 -05:00

Author

Owner

@simeononsecurity commented on GitHub (Mar 31, 2023):

It's easy, maintain a separate repo for nightly.
If you're going to install a nightly, potentially buggy release, it should be specific and determined by the users.
The base install, that should be going to debian should be somewhat stable...

@simeononsecurity commented on GitHub (Mar 31, 2023): It's easy, maintain a separate repo for nightly. If you're going to install a nightly, potentially buggy release, it should be specific and determined by the users. The base install, that should be going to debian should be somewhat stable...

deekerman commented

2026-02-20 23:05:49 -05:00

Author

Owner

@Jackenmen commented on GitHub (Mar 31, 2023):

In the meantime I've been distributing it over a private repository, for which the problem becomes the versioning. Development versions (nightly) do not tag the dev portion (pre-release for ex.) in their release schema. It makes it really hard to propagate new versions this way, since there is nothing telling the packaging managers about the new nightly actually being newer than the one the day before.

I do this as well and I just reversion those deb files with a release counter, i.e. my current rustdesk version is 1.2.0-0gemfury64. deb-reversion could be used, if not for the fact that rustdesk's deb file doesn't actually contain the required debian/changelog file. If that file were there, it's simply a matter of running something like fakeroot deb-reversion -v 1.2.0-0jackenmen1 rustdesk.deb. Personally, I just decided to reimplement what deb-reversion does in Python with some slight modifications and use that instead but asking for a debian/changelog file in another issue is also an option :)

@Jackenmen commented on GitHub (Mar 31, 2023): > In the meantime I've been distributing it over a private repository, for which the problem becomes the versioning. Development versions (nightly) do not tag the dev portion (pre-release for ex.) in their release schema. It makes it really hard to propagate new versions this way, since there is nothing telling the packaging managers about the new nightly actually being newer than the one the day before. I do this as well and I just reversion those deb files with a release counter, i.e. my current rustdesk version is `1.2.0-0gemfury64`. `deb-reversion` could be used, if not for the fact that rustdesk's deb file doesn't actually contain [the required `debian/changelog` file](https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#changelog). If that file were there, it's simply a matter of running something like `fakeroot deb-reversion -v 1.2.0-0jackenmen1 rustdesk.deb`. Personally, I just decided to [reimplement what `deb-reversion` does in Python](https://github.com/Jackenmen/sync-debs-to-gemfury/blob/main/src/sync_debs_to_gemfury/deb_reversion.py) with some slight modifications and use that instead but asking for a `debian/changelog` file in another issue is also an option :)

deekerman referenced this issue

2026-02-21 00:32:37 -05:00

MacOS 10.15.7 Mac Mini 2017 Crash on connect as target #2844