this post was submitted on 05 Jul 2024
741 points (94.0% liked)
linuxmemes
20464 readers
108 users here now
I use Arch btw
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules
- Follow the site-wide rules and code of conduct
- Be civil
- Post Linux-related content
- No recent reposts
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I think you're actually agreeing with me here. I was disputing the claim that software should be made available in "a native package format", and my counterpoint is that devs shouldn't be packaging things for distros, and instead providing source code with build instructions, alongside whatever builds they can comfortably provide - primarily flatpak and appimage, in my example.
I don't use flatpak, and I prefer to use packages with my distro's package manager, but I definitely can't expect every package to be available in that format. Flatpak and appimage, to my knowledge, are designed to be distro-agnostic and easily distributed by the software developer, so they're probably the best options - flatpak better for long-term use, appimage usable for quickly trying out software or one-off utilities.
As for tar.gz, these days software tends to be made available on GitHub and similar platforms, where you can fetch the source from git by commit, and releases also have autogenerated source downloads. Makefiles/automake isn't a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.
As for the Makefiles, I meant that for whatever build toolchain the project uses - because the rules to build a project are an essential part of the project, linking the source code into a working library or executable. Whether it is cmake, or gnu make, or whatever else there is - that's not so important as long as those build toolchains are available cross platforms.
I think what is really missing in the open source world is a distribution-agnostic standard how to describe application dependencies so that package maintainers can auto-generate distro-packages with the distribution-specific dependencies based on that "dependencies" file.
Similar to debian dependencies
Depends: libstdc++6 (>= 10.2.1)
but in a way that identifies code modules, not packages, so that distributions that package software together differently will still be able to identyfindPackageFor( dependency )
I would really like to add this kind of info to my projects and have a tool that can auto-build a repo-package from those.