Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add better and alternative application distribution for Linux users #2122

Open
haevalencia opened this issue Jun 7, 2016 · 26 comments

Comments

Projects
None yet
10 participants
@haevalencia
Copy link

commented Jun 7, 2016

I think that the discussion in #2108 should not be missed. The current distribution system is good, but it would be better considering #2063 and #1274 for example.
Another official distribution system independent of the OS would be very interesting and beneficial to users. I emphasize "official" because third parties already distributed Telegram with other package systems (*.deb *.rpm, AUR, PPA, Copr, Snap, etc) and not always have the latest client update.

Thanks

@grulja

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2016

I managed to create a flatpak manifest for telegram desktop client. In case you are interested see http://www.jgrulich.cz/2016/07/08/telegram-desktop-client-for-flatpak/.

@tdesktop-closer

This comment has been minimized.

Copy link
Collaborator

commented Aug 8, 2017

Hey there!

We're automatically closing this issue since there was no activity in this issue since 393 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.

Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

(Please note that this is an automated comment.)

@diazbastian

This comment has been minimized.

Copy link

commented Oct 24, 2017

For a while there is a flatpak version of Telegram that is currently distributed in flathub. As mentioned a couple of times in the flatpak mailing list, the original authors of the applications can request access to flathub to take control or simply distribute their application independently.

Considering that flathub will be the place of reference distribution of applications in flatpak format and its open policy, would be a good opportunity to promote an alternative method of distribution for Telegram Desktop.

@mmhyamin

This comment has been minimized.

Copy link

commented Apr 14, 2018

@auchri

This comment has been minimized.

Copy link
Member

commented Apr 14, 2018

@haevalencia

This comment has been minimized.

Copy link
Author

commented Sep 7, 2018

Is this version official? (Telegram FZ-LLC) https://snapcraft.io/telegram-desktop

The current version of flathub is official? I sincerely prefer this one because it's more distro-independent (Snap is well supported only on Ubuntu and Solus OS)

@john-preston

This comment has been minimized.

Copy link
Member

commented Sep 7, 2018

@haevalencia The snap version is going to be official, I didn’t have time to setup it’s build process yet, now it still uses the one from the guys who helped with it and provided the snap packaging initially.

I know nothing about flathub ;(

@haevalencia

This comment has been minimized.

Copy link
Author

commented Sep 8, 2018

@john-preston I see, personally as a user I'm not convinced though I appreciate your attention in gnu/linux users. As mentioned above, you can request the control of the Flatpak package in flathub (I have used it without problems in distros such as Endless OS or Clear Linux)

@grulja

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

Hi, as the author and maintainer of Telegram package in Flathub, I would be more than happy if you help maintaining it and make it official. I don't know about the Snap version, but the Flathub version uses Qt from KDE runtime, which has been major challenge we have been facing, building telegram against system Qt is not really trivial. Please feel free to ask any question you have.

Telegram in Flathub: https://flathub.org/apps/details/org.telegram.desktop
Manifest: https://github.com/flathub/org.telegram.desktop

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

@grulja With recent major problems (fontconfig 2 vs fontconfig 3 etc) with my initial (Windows / macOS) way of doing things I'm really interested in keeping it as a legacy way of distributing the app and make Snappy / Flathub (I guess both are required) the preferred official way.

In order to do this I'm required to keep both old build process available and make the correct packaging easy as well. Can you contact me at https://t.me/preston when you'll have time to describe what you think is the best way to improve the code / build process for this to work?

@Johnnynator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

@grulja With recent major problems (fontconfig 2 vs fontconfig 3 etc) with my initial (Windows / macOS) way of doing things I'm really interested in keeping it as a legacy way of distributing the app and make Snappy / Flathub (I guess both are required) the preferred official way.

In order to do this I'm required to keep both old build process available and make the correct packaging easy as well. Can you contact me at https://t.me/preston when you'll have time to describe what you think is the best way to improve the code / build process for this to work?

I just want to give my two cents as the maintainer of the tdesktop package @void-linux.
The main issue with the current build-system is that it is highly tailored towards you need to link a lot of libraries statically. It already would be a big relieve if the build-system would accept system libraries and therefore any step in the cmake build doc that mentions to clone a third party repo (except gyp and submodules) could be replaced by a system lib.

I personally would also be happy if tdesktop wouldn't use gyp but something better supported for linux applications like CMake directly or Meson (Meson would require some refactoring of the file structure). I use a custom CMake build system currently to work around some of gyp limitations (like cross compiling (but cmake is also a pain for cross compiling))

If you want I can help with either extending the gyp files to support sys libs or adding a different build system. I just don't want to start working on something properly without knowing how much use it has in the end.

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

@Johnnynator Please keep in mind, that current (statically linked) version is installed on a huge amount of machines / systems and they are required to get updates for a long time from now.

That means that the current build way (with static libraries) should be preserved at least with a switch, so that I could continue building the official binaries and autoupdate all those users.

So do you mean you want an easy way to configure build (for example by adding some switches to the .gyp / .gypi files) to use system libraries instead of static ones? Including Qt?

GYP is abandoned by Google, so perhaps it is a good idea to move from it somewhere. But that is not an easy task and I'm not sure what build system would give me all the same features. Tdesktop uses a lot of GYP features, like heavy inter-target dependency management (with library / executable targets), custom build actions and custom build rules for code generation, generating MSVC projects with Ninja backend and precompiled headers, Xcode projects with precompiled headers and AppStore sandbox support, CMake projects generation with precompiled headers for Linux builds.

@Johnnynator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

@Johnnynator Please keep in mind, that current (statically linked) version is installed on a huge amount of machines / systems and they are required to get updates for a long time from now.

That means that the current build way (with static libraries) should be preserved at least with a switch, so that I could continue building the official binaries and autoupdate all those users.

So do you mean you want an easy way to configure build (for example by adding some switches to the .gyp / .gypi files) to use system libraries instead of static ones? Including Qt?

Yep I know that the current behavior has to be preserved. Qt is a beast to build and most package maintainers (flatpak included) already use a patch to link against system qt.

GYP is abandoned by Google, so perhaps it is a good idea to move from it somewhere. But that is not an easy task and I'm not sure what build system would give me all the same features. Tdesktop uses a lot of GYP features, like heavy inter-target dependency management (with library / executable targets), custom build actions and custom build rules for code generation, generating MSVC projects with Ninja backend and precompiled headers, Xcode projects with precompiled headers and AppStore sandbox support, CMake projects generation with precompiled headers for Linux builds.

Meson should have most if not all of these features. I just don't know how the AppStore sandbox support is (Does this even depend on the build system). Only the code generation support is not as flexible as in e.g. CMake or gyp.

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

Build system generates Xcode project in macOS case. So it should generate Xcode project with the following sandbox settings being enabled and having correct values. I had patch GYP to allow it to do that :/

@bugaevc

This comment has been minimized.

Copy link

commented Oct 26, 2018

Best thing about meson is, it is not abandoned, and if it is indeed missing the features you need (I have no idea if it does) it's really easy to push the patch upstream.

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

@bugaevc It looks like Meson doesn't support generation Visual Studio solutions with a ninja build backend (made using custom build rules). Or perhaps I misunderstood something.

@Johnnynator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

bugaevc It looks like Meson doesn't support generation Visual Studio solutions with a ninja build backend (made using custom build rules). Or perhaps I misunderstood something.

https://mesonbuild.com/Using-with-Visual-Studio.html

If you wish to use the Ninja backend instead of vs2015, pass --backend ninja. At the time of writing the Ninja backend is more mature than the VS backend so you might want to use it for serious work.

@bugaevc

This comment has been minimized.

Copy link

commented Oct 26, 2018

You either use ninja in Windows or you use the VS build system, whatever it's called, but I assume @john-preston you want to combine both at the same time?

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 26, 2018

@bugaevc Yes, GYP allows me to generate MSVC solution (to use for debugging) where building is done through Ninja inside MSVC. I would not like to loose such way of working..

@Johnnynator

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2018

@bugaevc Yes, GYP allows me to generate MSVC solution (to use for debugging) where building is done through Ninja inside MSVC. I would not like to loose such way of working..

I think cmake directly would be possible to do this, since Visual Studio does afaik support CMake directly without the need to generate a msvc solution. But cmake afaik don't have proper pch support so it would still require custom support as you do it for linux currently. (And all this would probably result in a quite unreadable build system)
I can't name any build system that would tailor down to all these needs.

@john-preston

This comment has been minimized.

Copy link
Member

commented Oct 28, 2018

@Johnnynator Btw why GYP is a problem for native Linux builds? I thought it should add one command (before cmake) to the build process and that's it.

If the GYP version uses system libraries will it be fine for the proper Linux builds? Or is there a problem with the GYP itself? Like, how do you list the required system library dependencies for the app you're distributing?

@grulja

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2018

@john-preston I think using GYP is not a problem. I mean, it would be nice to use a build system which is still being developed, since you said that GYP is not abandoned by Google, but that can be done later. The major problem we are facing now is to build telegram against system libraries, mainly against Qt used in Flatpak KDE runtime. You can look at patches we use there, but it's mainly this one [1] and this CMake patch [2] which does the work. We of course use some other patches, but they are not related to static vs dynamic linking. Also some changes in the first patch just hardcode paths to some libs for flatpak specific usage, this could be I guess done better. Other problem we had was that we were forced to use GCC 8+, as you use lots of templates and c++17 features (I think) so we use specific flatpak extension.

[1] - https://github.com/flathub/org.telegram.desktop/blob/master/Avoid-depending-on-static-libraries.patch
[2] - https://github.com/flathub/org.telegram.desktop/blob/master/CMakeLists.inj

@Johnnynator

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2018

@Johnnynator Btw why GYP is a problem for native Linux builds? I thought it should add one command (before cmake) to the build process and that's it.

If the GYP version uses system libraries will it be fine for the proper Linux builds?

It would be fine for everyone but for me :D.

Or is there a problem with the GYP itself?

My main problem with gyp is cross compiling, it is hard to find proper documentation. Also the usage of uname in your gyp scripts. I only ever find documentation for gn. (But I can solve this myself later, I wouldn't call it a sever issue)

@grulja

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

Hi,

is there any progress on this? I noticed that now if someone wants to deploy Telegram, they need their own api_id, which complicates the process now. I wanted to update Telegram to 1.5.0 in Flathub and stopped on this. Maybe we can start working on making Flatpak/Snap the official builds? Telegram is among the most downloaded apps in Flathub (with 115k downloads) so it's definitely worth looking into that.

@john-preston

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

@grulja I'm working closely with the guys who prepared the snap version and already made it official (no information about that yet on desktop.telegram.org, but still). I hope we could do the same with flatpak version.

You can contact me about this on t.me/preston

@mmhyamin

This comment has been minimized.

Copy link

commented Jan 19, 2019

@haevalencia The snap version is going to be official, ...

There's no sign on snap store that it's official.

screenshot_2019-01-20 snap search results for

screenshot_2019-01-19 snap search results for

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.