Packaging for Linux

[syhlx]

Linux has multiple packaging formats for each distribution.

The idea is to reach as many Linux users as possible.

Please note, that Flatpak is out of the question for security reasons explained in this issue #1053.

@uazo

why? normally a linux user has more skills.

Not every Linux user is a sysadmin or a poweruser.
Additionally, making it more difficult or more "manual" to update Cromite is likely to result in out of date (and insecure) installations of Cromite.

explain to me how to make a repo for apt

As mentioned here #1053 (comment), I am suggesting Open Build Service which can automatically generate repositories for all major distributions of Linux.

OBS can be automatically triggered to build the packages from Github upon a new release of Cromite. The process could then be fully automated.

An APT repository would not be enough as not everyone uses Debian/Ubuntu based distributions of Linux.

[valtoree]

I asked ai, what was easier to build apt or other vs appimage. Ai said appimage. Here is the pastebin of the answer: https://pastebin.com/NZ5qhRHr
Its the best I can do to help 🤷

[syhlx]

Your AI is not wrong. AppImage is easier for maintainers, but not for users.

Here is a quick summary of ways to distribute applications on Linux:

1. AppImage

An AppImage is simply an entire application with all its files and dependencies stored in a single file. It is basically an executable ZIP archive.

Pros:

• Easy to package
• No installation required
• Portable (can run from USB drive)
• Not specific to any distribution of Linux

Cons:

• No automated updates
• Users are likely to store an run the file from a folder modifiable by any app

2. Packages

This is technically the proper way to install any application on Linux.

However, different Linux distributions use different packaging formats: Debian/Ubuntu -> DEB, RedHat/SuSE/Fedora -> RPM...

Pros:

• Automated updates (all applications are updated along with the rest of the system)
• Installed app files cannot be modified by another unprivileged application or script

Cons:

• Different packaging for different distributions
• Not portable: Immutable / read-only distributions might not be able to install it

3. Flatpak / Snap

Sandboxed applications distributed in a universal way.

Pros:

• Automated updates (all Flatpak / Snap applications are updated together)
• Not specific to any distribution of Linux
• Sandbox to limit the application's access to the system

Cons:

• As we saw, the provided sandbox can interfere with the application's own internal sandbox

[syhlx]

@uazo

Here is what I suggest:

Since, Open Build Service would allow Cromite to be packaged automatically as a RPM, DEB, AppImage... without any additional work on each release:

Give me some time to research how to use OBS as a maintainer and prepare everything while you focus on Cromite's development.

I have used OBS in the past, but always as a user, not as a maintainer.

[valtoree]

"Apes Together Strong" :)

P.s. bitwarden and tutanota appimage has auto update so that detail is incorrect. FEI (For Everyone's Information).
*made me own acronym, all copyrights are mine :P

[syhlx]

bitwarden and tutanota appimage has auto update so that detail is incorrect.

AppImages do not have a built-in update system.

Obviously, nothing is stopping an app from downloading itself to get its new version...

[archerallstars]

Another solution would be a script to set up a rootless Podman container for Cromite for unsupported systems. This is probably the most easiest route, and is also a more preferred approach on immutable systems if Flatpak/Snap is not supported.

[syhlx]

Another solution would be a script to set up a rootless Podman container for Cromite for unsupported systems. This is probably the most easiest route, and is also a more preferred approach on immutable systems if Flatpak/Snap is not supported.

Grabbing the latest release from Github with a script is already possible and can be done on any system without root access.

A simple script like this would suffice:

#!/bin/bash

installation_path="${HOME}/cromite"

release_version="$(curl -s -L 'https://api.github.com/repos/uazo/cromite/releases/latest' | jq .name | sed -e 's/"//g')"
installed_version=""

if [ -f "${installation_path}/cromite_version.txt" ]; then
	installed_version="$(cat "${installation_path}/cromite_version.txt")"
fi

if [ "${release_version}" = "${installed_version}" ]; then
	echo "Latest version of Cromite already installed: ${release_version}"
	exit
fi

echo "Downloading Cromite..."
curl --progress-bar -L -o "chrome-lin64.tar.gz" "https://github.com/uazo/cromite/releases/download/${release_version}/chrome-lin64.tar.gz" \
	|| (echo 'Error downloading release file'; exit 1)

mkdir -p "${installation_path}"
tar -xzf "chrome-lin64.tar.gz" -C "${installation_path}" --strip-components=1

strip --strip-unneeded "${installation_path}/chrome" "${installation_path}/chrome_crashpad_handler"
find "${installation_path}" -name '*.so*' -exec strip --strip-unneeded "{}" \;

printf "${release_version}" > "${installation_path}/cromite_version.txt"
rm -f "chrome-lin64.tar.gz"

echo "Cromite has been updated to the latest version: ${release_version}"

What we are trying to achieve here is having an automated way to update Cromite along with the rest of the system and applications.

The idea is trying to avoid users having to run something just to update Cromite.

[archerallstars]

The idea is trying to avoid users having to run something just to update Cromite.

With Podman and Distrobox as dependencies, and a systemd service to automatically check for the container update daily, Cromite would be updated in the background without the users' interaction.

[syhlx]

With Podman and Distrobox as dependencies, and a systemd service to automatically check for the container update daily, Cromite would be updated in the background without the users' interaction.

Which would accomplish the same task as the aforementioned script.

The bash script does not require additional dependencies and can be run automatically through a systemd service or a cron job.

[Fei1Yang]

Since, Open Build Service would allow Cromite to be packaged automatically as a RPM, DEB, AppImage... without any additional work on each release:

Even with OBS, it's still required to write packages manifests (RPM Spec file/DEB Control file) for each distribution family, therefore I would suggest to just build RPM/DEB packages using rpmbuild/dpkg-deb in Action release.yaml.

I have very little experience with DEB packaging and APT repository creation, however I have already created a GitHub Actions at feiyangprojects/rpm-repositories@cromite to generate a RPM repository of Cromite for myself and my friends using chrome-lin64.tar.gz and I would like to see it being integrated upstream.

[uazo]

however I have already created a GitHub Actions at feiyangprojects/rpm-repositories@cromite to generate a RPM repository of Cromite

@Fei1Yang I like it as a solution and I don't see any drawbacks.
would you explain the necessary setup for the client? so I can try it out.

[Fei1Yang]

however I have already created a GitHub Actions at feiyangprojects/rpm-repositories@cromite to generate a RPM repository of Cromite

@Fei1Yang I like it as a solution and I don't see any drawbacks. would you explain the necessary setup for the client? so I can try it out.

By client do you mean a package manager that can utilize the repository?

If so, it can be done via placing the following repository config file to /etc/yum.repos.d/cromite.repo on Red Hat distributions or /etc/zypp/repos.d/cromite.repo on SUSE distributions (the content of $URL is the public url of the directory containing generated repodata directory):

[cromite]
name=Cromite
enabled=1
autorefresh=0
baseurl=$URL
type=rpm-md
gpgcheck=1
repo_gpgcheck=1
gpgkey=$GPG_PUBLIC_KEY_URL
keeppackages=0

Then, it's possible to install the package via either dnf install cromite-stable or zypper install cromite-stable (assuming if you want to keep the Chrome style naming scheme I kept in my package manifest).

[syhlx]

@Fei1Yang

I was suggesting OBS for ease of use, but we can definitely handle all the repos through Github actions.

Since you already did the work for RPMs, that’s already one down.

I would say that supporting Debian/Ubuntu and Arch Linux on top of this should cover most of the main distributions and their variants.

There is already an AUR package for Arch, but a proper official repo would be better.

[uazo]

but we can definitely handle all the repos through Github actions.

Excuse my ignorance, does this mean that every linux distribution has its own format?
if that is the case, the solution is not applicable, I thought that when one was done, it applied to all.
how many different types of file should we have?

[syhlx]

does this mean that every linux distribution has its own format?

Originally, yes.
Which is why really wanted the Flatpak route to work. Flatpak being compatible with basically every Linux distribution.

That being said, most distributions are based on a few main ones.

how many different types of file should we have?

Ideally 3:

1. DEB

Debian's packaging format is used by:

• Debian
• Ubuntu
• Mint
• Zorin
• Pop!_OS
• elementary
• Raspbian

2. RPM

Red Hat's packaging format is used by:

• Red Hat / CentOS / Rocky / Alma
• Fedora
• openSUSE
• Nobara
• SuSE

3. Arch

Arch's packaging format is used by:

• Arch
• EndeavourOS
• Manjaro
• Garuda
• CachyOS

This is just to name a few. There are way too many Linux distributions which complicates... well... distribution of applications on Linux.

[syhlx]

Another route we could opt to take would be to motivate maintainers from some of the main Linux distributions to simply add Cromite to their repos.

Cromite is perfectly aligned with the Linux philosophy: open source, private, secure.
And, GPL-3.0 is basically the default Linux license.

Once the big distributions start to include Cromite, a lot of the others will follow suit.

[uazo]

open source, private, secure.

For open source, okay. Private and secure I still don't have the evidence. :(

If it's only 3 it's fine for me. However, it means I would have to have 3 different virtual machines to test them, and frankly, I have little desire to put them up. But I will try.

[PF4Public]

Another route we could opt to take would be to motivate maintainers from some of the main Linux distributions to simply add Cromite to their repos.

In my overlay for Gentoo since Sep 3, 2023: PF4Public/gentoo-overlay@c9daeaf :D

[olumolu]

What is the status for linux?

[l2nkxk8z]

What about homebrew for linux? it's not used much on linux but it's what ublue distros use. it can be installed on most distros since it's installed in home directory as far a I know.

[Samueru-sama]

1. AppImage

An AppImage is simply an entire application with all its files and dependencies stored in a single file. It is basically an executable ZIP archive.

Pros:

* Easy to package

* No installation required

* Portable (can run from USB drive)

* Not specific to any distribution of Linux

Cons:

* No automated updates

* Users are likely to store an run the file from a folder modifiable by any app

You do get automated updates with appimages if you pass the update information when using appimagetool, which will make a zsync file and the user can update with appimageupdate or some other appimage integration tool that makes use of it. For example both Zen Browser and Librewolf do generate that .zsync file.

We use it at AM to update appimages, we also have means to sandbox appimages with bubblewrap (although it isn't a good idea here?).

You also can implement your own auto-update mechanism since the appimageruntime sets the env variable $APPIMAGE which will contain the full path with symlinks resolved to the AppImage, meaning that you just need to download the new AppImage and replace $APPIMAGE with it.