Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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 support for more Linux distributions & packaging formats #213

Closed
lamergameryt opened this issue Feb 27, 2024 · 12 comments
Closed

Add support for more Linux distributions & packaging formats #213

lamergameryt opened this issue Feb 27, 2024 · 12 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@lamergameryt
Copy link

lamergameryt commented Feb 27, 2024

In the present state, the project is available as a package catering mainly to Arch Linux (pkgbuild), Debian (deb), and Red Hat (rpm) distributions. Furthermore, as evident from the blog post by @ashitaprasad at Medium, the packaging and distribution process is manual and cumbersome.

To solve this issue, there are a few steps we can take:

  • Create a CI/CD pipeline (using GitHub actions?) for automating the creation of a deb, pkgbuild, and rpm distributable file.
  • Work on issue #93: Package the application as a Flatpak for a more streamlined installation across multiple distributions.
  • Work on the issue #162: Create a build for nixOS and add it to the nixpkgs repository.
  • Package the application as a snap for distribution via the Snap Store.
  • Package the application as an AppImage to make the application portable across distributions.
@lamergameryt
Copy link
Author

@animator @ashitaprasad: Can you please add the Enhancement tag to this issue?

@animator animator added the enhancement New feature or request label Feb 28, 2024
@animator
Copy link
Member

@lamergameryt Instead of setting up a CI/CD pipeline right away, we want to first have clarity regarding the build process as you have read in the medium articles. So a good start will be to document the step by step build process for each distribution in this thread.

@animator animator added the good first issue Good for newcomers label Feb 28, 2024
@lamergameryt
Copy link
Author

@animator Sounds good; I'll document the build process for each of the above distributions as a separate comment in this issue. Starting with the step-by-step build process of a deb & rpm file, I'm using Pop!_OS 22.04 LTS x86_64 for building and testing the distributions.

Building a DEB Package

  • Clone the GitHub repository with git clone --depth=1 https://github.com/foss42/apidash.git
  • Install pre-requisites required for building: sudo apt-get install clang cmake git ninja-build pkg-config libgtk-3-dev liblzma-dev libstdc++-12-dev and sudo apt install rpm patchelf
  • Install flutter_distributor: dart pub global activate flutter_distributor
  • Create the necessary desktop files and directories required for building the project for Linux: flutter create --platforms=linux .
  • Create the make_config.yaml for DEB releases:
mkdir -p ./linux/packaging/deb
mkdir -p ./linux/assets

# Enter the download link for the actual png file here.
wget -O ./linux/assets/apidash.png https://example.org/image.png

cat > ./linux/packaging/deb/make_config.yaml << EOF
display_name: API Dash
icon: linux/assets/apidash.png
package_name: apidash
summary: A beautiful, lightweight, open-source cross-platform API Client
group: Applications/Development Tools
vendor: Ashita Prasad
packager: Ashita Prasad
packagerEmail: ashita@xyz.com
license: ASL 2.0
url: https://github.com/foss42/apidash

maintainer:
  name: Ashita Prasad
  email: ashita@xyz.com

priority: optional
section: x11
dependencies:
  - mpv

essential: false
postuninstall_scripts:
  - echo "Sorry to see you go."

keywords:
  - API
  - API Client

generic_name: API Client
categories:
  - Development
  - Utility

startup_notify: true
EOF
  • Build the DEB package using flutter_distrubution: flutter_distributor release --name=dev --jobs=release-dev-linux-deb

Building a RPM Package

Similarly, for building a RPM distributable file:

  • Create the make_config.yaml for RPM releases:
mkdir -p ./linux/packaging/rpm
mkdir -p ./linux/assets

# Enter the download link for the actual png file here.
wget -O ./linux/assets/apidash.png https://example.org/image.png

cat > ./linux/packaging/rpm/make_config.yaml << EOF
display_name: API Dash
icon: linux/assets/apidash.png
summary: A beautiful, lightweight, open-source cross-platform API Client
group: Applications/Development Tools
vendor: Ashita Prasad
packager: Ashita Prasad
packagerEmail: ashita@xyz.com
license: ASL 2.0
url: https://github.com/foss42/apidash

maintainer:
  name: Ashita Prasad
  email: ashita@xyz.com

priority: optional
section: x11
dependencies:
  - mpv

essential: false
postuninstall_scripts:
  - echo "Sorry to see you go."

keywords:
  - API
  - API Client

generic_name: API Client
categories:
  - Development
  - Utility

startup_notify: true
EOF
  • Build the RPM package using flutter_distributor: flutter_distributor release --name=dev --jobs=release-dev-linux-rpm

The above configuration works perfectly for creating DEB files. However, I'm encountering issues creating RPM files on my host machine.

warning: absolute symlink: /usr/bin/apidash -> /usr/share/apidash/apidash
I/O error : Permission denied
I/O error : Permission denied
Failed to write XML file; For permission problems, try rerunning as root

Despite this, the RPM file is successfully built and verified as OK with rpm -K apidash-0.3.0+3-linux.rpm. I tried rerunning as root, but I have to reinstall flutter_distributor as root. Hence, I'm still determining what needs to be done here. I am looking for your suggestions, @animator and @ashitaprasad.

@lamergameryt
Copy link
Author

  • Package the application as an AppImage to make the application portable across distributions.

I've added implementing this application as an AppImage package to the scope of this issue to make the application portable and run everywhere.

@Tanish2002
Copy link
Contributor

@animator @ashitaprasad One easy way to distribute for linux is to just provide a tarball of the bundle generated by flutter build.

You can create this tarball using:

  1. flutter build linux --release (add the --target-platform flag as needed)
  2. cd into ./build/linux/x64/release/bundle
  3. create tarball for the files inside this directory using: tar -czvf apidash_x64-linux.tar.gz * (Here x64 can be replaced with the corresponding target platform.)

This tarball will contain the binary, the assests, and the linked libs. Which a packager can easily use to package the app.

Extra Notes:

  • Distro-specific packages (.deb, .rpm) are even more convenient for end-users, but they take more work to create.
  • The tarball method gives packagers a simple way to get started and support many Linux users quickly.

I can provide some examples of repos distributing their project through tarballs.

@ashitaprasad
Copy link
Member

@lamergameryt Why are you summarising the article for .deb and .rpm? That is sorted out and well documented by our team. What @animator said is to document the steps for build process for Linux platforms other than the ones we already have (.deb & .rpm).

@ashitaprasad
Copy link
Member

@Tanish2002 When you are creating .deb & .rpm you can specify external dependencies.
How can you do the same for the tarball?

@Tanish2002
Copy link
Contributor

Tanish2002 commented Mar 1, 2024

@Tanish2002 When you are creating .deb & .rpm you can specify external dependencies. How can you do the same for the tarball?

@ashitaprasad

Dependencies in Apidash

  • Dynamically Linked Libraries: When Flutter builds an app for Linux, all required libraries are placed in the ./libs folder which is inside the bundle folder. These will be included in the tarball.
  • External dependencies: Currently, Apidash doesn't rely on external dependencies from what I've seen. Even if it does in the future, Tarballs are not supposed to be a package, (refer to the section below).

Tarball Purpose:

  • The tarball is not a complete, self-contained package.
  • It serves as a base to make packaging easier for maintainers.
  • Maintainers need to place the binary and libraries in the correct system locations, create .desktop files and include any external dependencies.
  • Tarballs eliminate the need for package maintainers to know how the flutter toolchain work and also the need for them to install it.

Tarball as a Tool for Package Maintainers:

  • Maintainers can easily download the tarball using wget or curl.
  • This approach simplifies packaging for both the maintainers and repository managers.

Caveats with Pre-built Binaries:

  • Some distros (like OpenSUSE) don't allow pre-built binaries in packages However, most distros do permit this, making packaging much simpler.
  • Though with distros that don't allow prebuilt binaries can simply build from source like we're currently doing for deb and rpm packages.

Ending Notes

  • Tarball Advantage: Maintainers seeking a simpler packaging process can use the provided tarball. They don't need to understand the Flutter toolchain.
  • Building from Source: Maintainers who must build from source (due to distro guidelines or preference) can still do so by cloning the repo and using the release tag.

@animator
Copy link
Member

animator commented Mar 1, 2024

  • External dependencies: Currently, Apidash doesn't rely on external dependencies from what I've seen. Even if it does in the future, Tarballs are not supposed to be a package, (refer to the section below).

Note: API Dash currently has mpv as external dependency.

@Tanish2002
Copy link
Contributor

Didn't know that. What library depends on mpv?

@animator
Copy link
Member

animator commented Mar 1, 2024

Didn't know that. What library depends on mpv?

just_audio_mpv

@animator
Copy link
Member

animator commented Mar 2, 2024

We are converting this issue into a discussion.

@foss42 foss42 locked and limited conversation to collaborators Mar 2, 2024
@animator animator converted this issue into discussion #240 Mar 2, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants