Add desktop build for Linux

Continuing the discussion from New website design:


We distribute desktop client binaries for Windows and MacOS but not for Linux.
I found three options to distribute desktop client on Linux:



  • Single file to download


  • No repository
  • No example for Python nor GTK
  • Not sand-boxed




  • No single file
  • Requires flatpak installed




  • No single file
  • Requires snapd installed
  • Controlled by Ubuntu
  • AppImage
  • Flatpak
  • Snap

0 voters



1 Like

Having this feature would allow to get the update notification inside the client which already exist for other builds.

While snap automatically updates when a new version is available. There is an option in snap to track branches that could be used to specify major tryton versions.

I guess it is something like pinning on Debian, but I think this will be quiet complicate for the average user and we will have less control on it than our current notification.

While I understand that the point is to have a extra unix button on the download page I am not sure introducing a new binary format for them is worth it.

Shouldn’t we just mention to our linux/bsd users that they should use whatever packaging system their OS use to install Tryton if available? It seems like this is the best practice anyway and if they want to have a more complicated setup then it’s up to them anyway.

For me, there are some issues with distribution packages. Tryton is not packaged in all distributions and the current trend is to have less distribution. In (almost) all distribution packages, the user can only install one version of the client. This can be a problem for users having to connect to different versions or if the update is not synchronized between the server and all the client OS. Also the change of series in the distribution package is not managed/scheduled by the company using Tryton.
So their only solution is to repackage Tryton to follow their own agenda. I think Tryton will help the deployment by providing binaries for each series.


I prefer AppImage. I have several programs running on AppImage and haven’t any problem with that. See and for an example.

I would be interested by knowing distributions that permit installation of several differents clients version (and how it is done).

The problem for packaging is that all tryton clients uses the same namespace at module level (tryton). So as currently distributed, the different versions are incompatible. it is additional work for distribution to provide a not standard installation that let them work together.

If the project provide a script that install python modules in separate modules (tryton50, tryton51, …) and I think no distributions will complain and all of them will have the possibility to install multiple versions of tryton desktop client.

I don’t think the idea is to install many versions at the same time but to choose which version to install, as the tryton server might have a different version than the one available in the distro repositories.

I agree that giving the user the flexibility to choose which version to install is important.

Indeed it is similar to Debian pinning.

I do like the self updating way snap works, though and how it reduces the end-user’s responsability on keeping the client updated.
Is the average user responsible for installing their own client? I’d expect that they are instructed or that software are installed in the computer by someone else than the average user. If that is the case, using a self updating client would reduce the effort of that person and the extra worry for the end-user to keep their client updated.

I don’t think this is a problem for the end user.
The company will have one production server on which people will connect using only one version of Tryton.

But this is an issue for people that are implementing Tryton in their organisation. Usually we can expect them to be able to manage different virtual environments but few might not be able to do so. The question is this worth the effort of supporting another binary distribution?

You pointed to pinning as a way to circumvent that issue. But I agree that when a distribution skip a package (like debian did some time ago) or when the maintainer stops there is an issue.

1 Like

It is difficult to answer because we do not know the cost of it because we do not know which format yet.
Also the cost of the other binary is very low now because we rely on distribution like msys2 and bottle.
As far as I see, AppImage is quite similar to Docker in the sense that you start from a “distribution” and install your application in it. (I guess the others are similar). So for me, the main cost will be the initial setup. The maintenance cost will be very low.