741
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 05 Jul 2024
741 points (93.7% liked)
linuxmemes
21281 readers
294 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't fork-bomb your computer.
founded 2 years ago
MODERATORS
While I agree that developers (like myself) are not necessarily experts at packaging stuff, to conclude that it's fine that a developer provides a flatpak is promoting shitty software. Whether a software should run in a jail, or within user space is a decision that - for most use cases - should be made by the user.
There is absolutely no reason not to provide software as a tar.gz source code archive with a proper makefile & documentation of dependencies - or automake configuration if that's preferred.
From that kind of delivery, any package maintainer can easily build a distro-package.
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.