Our great sponsors
-
httm
Interactive, file-level Time Machine-like tool for ZFS/btrfs/nilfs2 (and even actual Time Machine backups!)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
bedrocklinux-userland
This tracks development for the things such as scripts and (defaults for) config files for Bedrock Linux
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
My best advice (from a person who knows only enough to package his own projects) is it depends on the project. For my own Rust projects, I've found a Debian autopackager called cargo-deb for cargo. I convert those deb packages to rpm with alien. I upload both to the repo manually, and have a script which generates what I need and uploads to a PPA.
My best advice (from a person who knows only enough to package his own projects) is it depends on the project. For my own Rust projects, I've found a Debian autopackager called cargo-deb for cargo. I convert those deb packages to rpm with alien. I upload both to the repo manually, and have a script which generates what I need and uploads to a PPA.
Have you seen https://bedrocklinux.org/ ? When I found that I thought "yes, that's how it should be".
In order to understand why, it helps to understand Semantic Versioning. Not every system component conforms to semantic versioning, but let's start there anyway. In software that conforms, developers restrict the types of changes that they make to different types of releases. There are patch releases that only fix bugs, and feature releases that might add new interfaces, and major releases that might change existing interfaces in incompatible ways or deprecate old and unwanted interfaces and features. The benefit of this system is that users of components that conform get a lot of information about compatibility, based on just the version number. They know that if they build against a specific version of the dependency, the compiled application should continue working on any version with the same version number, or any higher version number, as long as the major version doesn't change. That is, if the application is built against 1.3.1, then it should also work with 1.4.0 and 1.5.5, but not necesarily with 2.0.0.
I'm not sure why you said it is difficult to distribute Flatpaks outside of Flathub. On the repo host side elementary has their own Flatpak repo complete with an app payment system (before even Flathub has one). On the user side I can simply download a .flatpakref from appcenter.elementary.io and double click it, which will open Software with the app's metadata, and clicking Install will add the repo and install the app.