{"action":"created","issue":{"url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/2865","repository_url":"https://api.github.com/repos/MovingBlocks/Terasology","labels_url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/2865/labels{/name}","comments_url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/2865/comments","events_url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/2865/events","html_url":"https://github.com/MovingBlocks/Terasology/issues/2865","id":217677879,"number":2865,"title":"Improving packaging of the whole game","user":{"login":"qwc","id":1408353,"avatar_url":"https://avatars1.githubusercontent.com/u/1408353?v=3","gravatar_id":"","url":"https://api.github.com/users/qwc","html_url":"https://github.com/qwc","followers_url":"https://api.github.com/users/qwc/followers","following_url":"https://api.github.com/users/qwc/following{/other_user}","gists_url":"https://api.github.com/users/qwc/gists{/gist_id}","starred_url":"https://api.github.com/users/qwc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qwc/subscriptions","organizations_url":"https://api.github.com/users/qwc/orgs","repos_url":"https://api.github.com/users/qwc/repos","events_url":"https://api.github.com/users/qwc/events{/privacy}","received_events_url":"https://api.github.com/users/qwc/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2017-03-28T20:09:58Z","updated_at":"2017-04-08T15:55:42Z","closed_at":null,"body":"Due to the recent talk at slack about packaging I thought about writing down my thoughts on packaging of terasology.\r\n[Forum discussion thread](http://forum.terasology.org/threads/terasology-packaging-linux-distros-windows-mac-discussion.1847/)\r\n\r\n# Terasology Variants\r\n\r\nFirst of all I would see 3 package variants of terasology\r\n1. The Launcher - the universal desktop approach, easiest for beginners too\r\n2. Latest Stable (Omega release)\r\n3. Latest Unstable (Omega release)\r\n\r\n2/3 Would be best for setting up servers without docker.\r\nOn Linux if the user wants to get updates through the distribution and not with some manual clicks inside the launcher. (May also be good for ppl with slow internet connections to get the latest version with the distribution update instead of when they just want to play and realize they have to download first to play)\r\n\r\n## Package signing\r\n\r\nI think it would be good to also implement package signing so that downloaded packages can be verified.\r\n\r\nThings to discuss here are\r\n- pgp/gpg signing\r\n  - how to achieve automatic signing with high enough security for the key\r\n  - should multiple ppl know/have the private key?\r\n  - can be done 'offshore', and maybe should be done on a separate system (private key security)\r\n- md5/sha2/sha512 etc. should be standard and no problem to implement.\r\n  - **already implemented on terasology jenkins, md5sums.txt and sha256sums.txt are included into the artifacts**\r\n\r\n# Linux distributions to target\r\n- debian based (.deb)\r\n  - ubuntu [already existing, got permission to use!]\r\n  - Mint\r\n  - alot more!\r\n- rpm based (fedora, SuSE, etc.) (.rpm)\r\n- Arch Linux based (.tar.xz) [already existing in aur, got permission to use!]\r\n- gentoo based\r\n\r\nDid I forget a distribution type with reasonable user base? O.o\r\n\r\n@qwc is working on these.\r\n\r\n## Linux distribution independent packaging\r\n- snap\r\n- flatpak\r\n- appimage\r\n\r\n@qwc is working on these also\r\n\r\n# Windows packaging\r\n\r\n- Chocolatey?\r\n- Installer?\r\n- downloadable archive?\r\n- downloadable executable?\r\n\r\n**@gianluca-nitti is working on this.**\r\n\r\n# Apple MacOS \r\n\r\nWell, here I have quite a bit of a lack of knowledge. I know there are at least four things to consider:\r\n- .dmg Apps\r\n- MacPorts, if that is still an approach to install software on Apple's Darwin Unix system...\r\n- homebrew\r\n- Apple's AppStore ... There I have fears to get the approval from the Apple guys and how that works in general...\r\n\r\n**Expert knowledge needed!**\r\n@skaldarnar put **homebrew** on his list.\r\n\r\n# docker\r\nFinally the docker solution for servers and hosting platforms, provided by my [docker-terasology](https://github.com/qwc/docker-terasology) project\r\n- Stable\r\n- Unstable\r\n\r\nMaybe with predefined configurations and more customization in the future, needs to be discussed.\r\n\r\n# Important: automation\r\nEverything mentioned must run through an automated job on a jenkins instance of the project (I'm so brash to include my own instance here).\r\n\r\n# Final words...\r\n\r\nSo far my thoughts to how the future variants could look and which package formats to target.\r\n\r\n**Human resources thoughts and claims for this tasks:**\r\nSo, come what may, but I'll at minimum claim the docker kill, that was my first contribution for terasology  and I'll keep that baby. ;)\r\nI am familiar with all mentioned linux distributions and already packaged software for all of these (although it may be some time since then...) so I can do that basically, or may mentor ppl who want to do them. snap and flatpak are new to me, but I know basically what those projects want to achieve so it's not that hard to understand those formats.\r\n\r\nOn Windows - I'm almost gone, but already wrote some installers (WiX, and an other I cant remember...).\r\nOn Mac - I'm completly gone.\r\n\r\nAn own repository for the packaging scripts may be needed, at least for all those linux distros I would wish for one. One for Win and Mac and we're done. "},"comment":{"url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/comments/292726759","html_url":"https://github.com/MovingBlocks/Terasology/issues/2865#issuecomment-292726759","issue_url":"https://api.github.com/repos/MovingBlocks/Terasology/issues/2865","id":292726759,"user":{"login":"gianluca-nitti","id":15270303,"avatar_url":"https://avatars3.githubusercontent.com/u/15270303?v=3","gravatar_id":"","url":"https://api.github.com/users/gianluca-nitti","html_url":"https://github.com/gianluca-nitti","followers_url":"https://api.github.com/users/gianluca-nitti/followers","following_url":"https://api.github.com/users/gianluca-nitti/following{/other_user}","gists_url":"https://api.github.com/users/gianluca-nitti/gists{/gist_id}","starred_url":"https://api.github.com/users/gianluca-nitti/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gianluca-nitti/subscriptions","organizations_url":"https://api.github.com/users/gianluca-nitti/orgs","repos_url":"https://api.github.com/users/gianluca-nitti/repos","events_url":"https://api.github.com/users/gianluca-nitti/events{/privacy}","received_events_url":"https://api.github.com/users/gianluca-nitti/received_events","type":"User","site_admin":false},"created_at":"2017-04-08T15:55:42Z","updated_at":"2017-04-08T15:55:42Z","body":"I have another consideration, I'm not sure if I should post it here, on the forum thread or on my installer's PR. Writing here since I think this can be relevant for every platform.\r\n\r\nAs @qwc says in the opening, for desktop clients the launcher is what should be packaged for desktop clients (opposed to headless servers) since it allows to switch between versions easily. I just found out, however, that the launcher has an [auto-update system](https://github.com/MovingBlocks/TerasologyLauncher/tree/develop/src/main/java/org/terasology/launcher/updater) which is used to [self-update the launcher files](https://github.com/MovingBlocks/TerasologyLauncher/blob/develop/src/main/java/org/terasology/launcher/updater/SelfUpdater.java). However, in most setups these would probably be put in system-wide locations (e.g. I imagine something like `/opt` in Linux, and my Windows installer currently uses `%programfiles%` which expands to `C:\\Program Files`; no idea about macOS) which are usually read-only for a normal user; thus, the self-update wouldn't work. In my opinion the possible solutions are:\r\n* Disable the self-update in the launcher when it is built for packaging (i.e. for Linux packages or for the Windows installer) while leaving it enabled when building zip/tar distributions which the user would likely put somewhere he has write access to. The packaged versions could simply show a message suggesting the user to update through apt/pacman/chocolatey/whatever or to download the new installer and run it; after all, probably launcher updates shouldn't be very frequent.\r\n* Keep the self-updater and somehow ask for the superuser rights when it needs to run (which would require the user to enter the password); there is a way to do it in Windows (a separate small exe with a special manifest, if I recall correctly) and there are various options on Linux like [GKSu](http://www.nongnu.org/gksu/) and [PolKit](https://www.freedesktop.org/wiki/Software/polkit/).\r\n\r\nThe second one feels weird in my opinion, updating a package is usually done by package managers or installers."}}
{"actor":{"display_login":"gianluca-nitti"}}