DavidoTek / ProtonUp-Qt

Install and manage GE-Proton, Luxtorpeda & more for Steam and Wine-GE & more for Lutris with this graphical user interface.
https://davidotek.github.io/protonup-qt
GNU General Public License v3.0
1.23k stars 40 forks source link

Packaging as a deb file #69

Open dnet890 opened 2 years ago

dnet890 commented 2 years ago

Hi Is there any possibility for deb file for this app?

DavidoTek commented 2 years ago

Hi, my original plan was to only distribute distro independent packages (AppImage, Flatpak) to decrease maintainace work and don't confuse anyone.

It would be possible to publish ProtonUp-Qt in the official Debian repos, but someone would need to maintain it and I personally have no experience with it. Also the version would be behind the Flathub version. Alternatively I could automatically build a deb file using GitHub Actions, but we would loose the ease of updating this way.

What would be the advantage of providing a deb file/putting it in the repos over using Flatpak/AppImage? I think all modern/gaming "oriented" distros will at least support one of these packages.

dnet890 commented 2 years ago

Foremost. Steam support debian based distro in the first of place and (I know Flatpak/Appimage cover lots of distros and it is okay). Finally, Debian based distro have similar feature called deb-get (https://github.com/wimpysworld/deb-get). it would be nice if we have other alternatives. what do you think?

DavidoTek commented 2 years ago

Okay. I think having Flathub as a primary is source is fine, but I see your point and having alternatives is good. I guess both GitHub Releases as well as deb-get are mostly used by advanced users, so it shouldn't confuse beginners either.

So I will have a look at building a deb package with GitHub Actions.

dnet890 commented 2 years ago

@DavidoTek that means ProtonUp-Qt will abandoned deb release and in favor of the Pacstall. Is that so?

DavidoTek commented 2 years ago

I may release a deb file for ProtonUp-Qt in the future, though I haven't planned to do so now (I'm happy to accept a PR regarding this).

You're right, I should reopen the issue as it is something different than Pacstall.

gryffus commented 1 year ago

+1 for a sane packaging (deb, rpm) There are many people that avoid any containerized application due to security (and other) issues. Some examples: https://www.flatkill.org/ https://hackaday.com/2020/06/24/whats-the-deal-with-snap-packages/

By using Open Build Service (1) (which is a free to use and open source), you can build native packages for rpm-based and deb-based distribution automatically. It has even a github integration. I can also help with the packaging, it is not really such a problem as might seem from the first looks.

Anyway, I am one of those people that will never touch anything like Flatpaks, Snaps, or whatever. I trust my distribution (and myself) about library versions and their updates, nobody else.

(1): https://openbuildservice.org/

DavidoTek commented 1 year ago

I think installing via Flatpak probably is the best for most people, yet I agree that having other choices is good. I already had OBS in mind but didn't get to try it until now.

I can also help with the packaging, it is not really such a problem as might seem from the first looks.

I would appreciate that. Where is the best place to start and how well can the CI be integrated with GitHub releases?

gryffus commented 1 year ago

I would appreciate that. Where is the best place to start and how well can the CI be integrated with GitHub releases?

I would recommend creating account @ build.opensuse.org and check some packages there for inspiration. Just send me a link to your repository and i will try to help as much as I can (creating proper .spec file etc).

Then, check this guide for reference about CI integration https://linuxkamarada.com/en/2019/03/19/integrating-the-open-build-service-with-github/

Basically, you setup a "source service" that fetches the source from github (for example from specified branch) and then you configure a github webhook to trigger the builds when you want (for example when you do a new commit).

deri821 commented 1 year ago

+1