[simiones]

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

[ilyt]

> It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

> Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

Technically incorrect as you can put (at least in apt) filters on what's allowed from the repo

Also, you want to have your cake and eat it too.

Either there is some 3rd party to look at package quality (even if "quality" in this case is "does not fuck up other stuff" and "uninstalls properly"),

or you trust developer to not fuck you over when they update the package

or you don't and only install raw .deb file.

> You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

Main difference is that package can require system deps (so you will be sure that they are not removed on accident) and you don't need to write uninstaller for it.

[derefr]

> but that actually asks your users for even more control of their systems

Or you can support one of the limited-capability package ecosystems, like Flatpak or Snap or AppImage. Then it's sort of like installing an app on your Android phone: the installed app (and its updates) only get to interact with the system through a customized sandbox that must first be described to, and accepted by, the user.

[simiones]

Sure, but there is plenty of software for which that doesn't make any sense, since the whole point is to interact with your system. ohmyzsh is a good example, as are most SDKs, as is plenty of specialty software.

[derefr]

SDKs are an interesting case — it wouldn't work to package them into a sandbox by default, but do look at how macOS treats XCode for an example of how something can be "sandboxed" but still reach out into the system by the system instead actually reaching into it. A thin layer of non-sandboxed system components on macOS "expect" XCode, and so work with it if it's available, to extract specific sandboxed data from the XCode sandbox and so "publish" it into being standalone software (rather than software that ends up also running inside the XCode sandbox.)

Essentially, an SDK in this sense would be a sandboxed plugin for a non-sandboxed system-level meta-SDK manager, that knows how to use these SDKs (in their sandboxes!) to compile and/or test-run things; where a test-run gets granted capabilities that the SDK-as-compiler does not itself possess, per a capabilities manifest fed in with the meta-SDK development project.

[AnIdiotOnTheNet]

AppImage is not "limited-capability" and has no sandbox mechanism at all without additional tools. An AppImage is the rough equivalent of a statically compiled binary.