Skip to content
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

Create a small set of Linux distro package releases #18

Open
chrissimpkins opened this issue Mar 26, 2021 · 2 comments
Open

Create a small set of Linux distro package releases #18

chrissimpkins opened this issue Mar 26, 2021 · 2 comments

Comments

@chrissimpkins
Copy link
Member

Probably:

  • deb
  • rpm
  • pacman
  • tar.gz
@daniel-j-h
Copy link

I just found this wonderful app and just wanted to leave another option here: flatpak and distributing through https://flathub.org

This would make it distribution-agnostic and you'd be in control of the releases and how and when to package it up.

@alerque
Copy link
Member

alerque commented Jan 18, 2024

As a general rule upstream projects that generate packages for specific distros do it wrong or shouldn't be doing it at all. It depends some on the target of course. It's easy to get away with on very slow moving ones like Debian and Ubuntu, and easy-ish to target ones with fixed versioning and package freezes ike Fedora, but it absolutely falls apart when targeting rolling release distros like Arch Linux, openSUSE, Nix, PLD, Homebrew, etc.

The issue in broad terms is that the release cycle of projects like this one does not match the release or rebuild cycles of distros, and packages need to match the latter not the former. That's the main reason distro package repositories exist in the first place, and why even distros that don't accept outside contributions to those often have user repositories (the Arch Linux AUR, Ubuntu PPAs, etc).

For example Arch Linux does not support packages built against anything except the current most recent version of all dependencies. As such packages frequently need rebuilding to properly support that, and the only way to handle that properly is if they are managed through the distro package rebuild system.

If people want slice on Arch they can use this AUR package using their favorite AUR tooling (yay -S slice or paru -S slice or whatever), and if they want a pre-built variant they can install it from the user package repository that I host.

The same goes for many other distros. Respectfully I suggest the best solution is to submit recopies to ustream distros somewhere they can be managed and updated on a cycle that matches the distro not the app release cycle. Not all of them accept outside contributions, but some do and that will raise discoverability and awareness and others will follow suit when somebody requests a package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants