4 ms·

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packagin

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal.

simiones 4y ago
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.
- derefr 4y ago
  > 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 4y ago
    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 4y ago
      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 4y ago
    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.
- ilyt 4y ago
  > 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 4y ago
> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some kind of medical/legal-like software-engineering bar association) that devs either properly package their apps, or don't release them at all. I'm not saying it's a good idea; just saying that it's probably the solution brewing in the back of the minds of people who write things like this.
- mynameisvlad 4y ago
  I mean, that will just result in no software ever getting made outside of big companies who can afford entire departments of people specializing in packaging. If someone were to impose restrictions to the hobby things I do, then those hobby things will just become private repositories that will never see the light of day, and I'm sure that rings true for most people.
- mustache_kimono 4y ago
  > "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he shouldn't be downvoted for making an unpopular yet interesting point.
  - Brian_K_White 4y ago
    Yet somehow as a developer I have no problem at all realising that it is user-hostile to take liberties with their system. It's violating trust and I have no need to do it in order to provide, even to install, a piece of software.
    - 4y ago
bombcar 4y ago
Even if omz had a package-managed package, it would do the basic curl|bash itself the moment it was installed, to update itself. Technically it's git and things, but that's all the curl|bash does anyway.
bravetraveler 4y ago
With things like the OpenSUSE build system... I see this more as a one time cost You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever With that you parameterize the inputs. The version to build, where to get the sources, etc. Maintaining these is... note your build/runtime requirements the same way you do while developing. Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own. I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it. This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.
- mustache_kimono 4y ago
  > I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it. I've heard a lot about these systems, and, if they do what they promise, I think this is great. Exactly what is needed. I already do package and distribute my software. My comments are mostly directed at those who have a problem with those who don't, because that's a fine choice too. It can also be a fine choice for awhile. The problem is mostly one of attitude, we need less user entitlement re: packages. Packages are something I will get to if I want to, when I have the time, and if it interests me. I would note there are other problems with the package manager ecosystem which make it ill-suited to packaging Rust apps, for instance. I am not an Arch user, but Arch really is leading the way here: https://wiki.archlinux.org/title/Rust_package_guidelines https://wiki.archlinux.org/title/Rust_package_guidelines
  - bravetraveler 4y ago
    Thank you for the packages you do maintain! I don't want to seem unappreciative for the work developers like yourself and others do; packages or not. I'm not a developer, but a Linux/systems person who happened to learn packaging. Mostly because I got tired of building from source, and figured others were too. As a maintainer it is easy for me (and others) to trivialize this, as compared to actually writing the much more complicated software. It's not right, and I think we could all use more understanding. I see a meme that 'packaging is hard', and while very rigid/plain, it's not actually that tough. Priority is another matter, I just don't want this notion of difficulty to unfairly sway that priority. Many of the concepts reapply, like languages. The tooling/services have improved a lot I'm not too familiar with Rust, unfortunately. What would you say makes Arch stand out in particular? How do you feel about Fedora? https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...
ilyt 4y ago
The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update) > devs don't like packaging for every distro under the sun source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unless you have some funky dependencies (and if you do, installer will also be complex) RHEL/Centos RPM will cover near-whole rest of the market. MacOS/FreeBSD will be different enough anyway that you will need to write a bunch more in install script Building simple package that just delivers binary is not even that complicated. Getting them to pass distro muster is often harder but you don't need to do that. > Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal. Most of those "arcane" policies are there so random incompetent dev won't fuck up other stuff in the system. Which is also why users want packages in the first place. And you don't need to abide to any policy to make simple package that just puts your files on the system. Building dumb debian package is just few metadata files (post/preinst scripts + a file describing your package) in a directory and a single command. You only need to worry about policies if you want to submit package to distro, and there are in place for a reason. No shit they are better for users, that's their entire fucking point!
- mustache_kimono 4y ago
  > No shit they are better for users, that's their entire fucking point! I'm not even sure we disagree about anything, and you're yelling? FWIW I package and distribute my software but for a long time I didn't. My position is very simple -- it's always easier if someone else does the work for you. If someone chooses not to distribute with a package, that's fine. If it bothers you, the choice is to build a package spec and pipeline for that project, not to moan about it. But packages are not an entitlement of a non-paying user. That user is perfectly entitled not to use your software, because complaining about the packages you may or may not have available is stupid, and not the devs problem.

simiones 4y ago

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.

derefr 4y ago
> 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 4y ago
  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 4y ago
    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 4y ago
  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.
ilyt 4y ago
> 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 4y ago

> devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro I mean, no, those aren't the only two solutions. As with accessibility requirements for public-access shops, "we the users" could mandate (either through legislation, or more interestingly, through some kind of medical/legal-like software-engineering bar association) that devs either properly package their apps, or don't release them at all. I'm not saying it's a good idea; just saying that it's probably the solution brewing in the back of the minds of people who write things like this.

mynameisvlad 4y ago
I mean, that will just result in no software ever getting made outside of big companies who can afford entire departments of people specializing in packaging. If someone were to impose restrictions to the hobby things I do, then those hobby things will just become private repositories that will never see the light of day, and I'm sure that rings true for most people.
mustache_kimono 4y ago
> "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he shouldn't be downvoted for making an unpopular yet interesting point.
- Brian_K_White 4y ago
  Yet somehow as a developer I have no problem at all realising that it is user-hostile to take liberties with their system. It's violating trust and I have no need to do it in order to provide, even to install, a piece of software.
  - 4y ago

bombcar 4y ago

Even if omz had a package-managed package, it would do the basic curl|bash itself the moment it was installed, to update itself. Technically it's git and things, but that's all the curl|bash does anyway.

bravetraveler 4y ago

With things like the OpenSUSE build system... I see this more as a one time cost You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever With that you parameterize the inputs. The version to build, where to get the sources, etc. Maintaining these is... note your build/runtime requirements the same way you do while developing. Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own. I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it. This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.

mustache_kimono 4y ago
> I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it. I've heard a lot about these systems, and, if they do what they promise, I think this is great. Exactly what is needed. I already do package and distribute my software. My comments are mostly directed at those who have a problem with those who don't, because that's a fine choice too. It can also be a fine choice for awhile. The problem is mostly one of attitude, we need less user entitlement re: packages. Packages are something I will get to if I want to, when I have the time, and if it interests me. I would note there are other problems with the package manager ecosystem which make it ill-suited to packaging Rust apps, for instance. I am not an Arch user, but Arch really is leading the way here: https://wiki.archlinux.org/title/Rust_package_guidelines https://wiki.archlinux.org/title/Rust_package_guidelines
- bravetraveler 4y ago
  Thank you for the packages you do maintain! I don't want to seem unappreciative for the work developers like yourself and others do; packages or not. I'm not a developer, but a Linux/systems person who happened to learn packaging. Mostly because I got tired of building from source, and figured others were too. As a maintainer it is easy for me (and others) to trivialize this, as compared to actually writing the much more complicated software. It's not right, and I think we could all use more understanding. I see a meme that 'packaging is hard', and while very rigid/plain, it's not actually that tough. Priority is another matter, I just don't want this notion of difficulty to unfairly sway that priority. Many of the concepts reapply, like languages. The tooling/services have improved a lot I'm not too familiar with Rust, unfortunately. What would you say makes Arch stand out in particular? How do you feel about Fedora? https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/ https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...

ilyt 4y ago

The effort to package is precisely what the complaint is about; you have to tell (in package manifest) where your files land and which are app files (to be removed freely) and which are config (user might want to leave it, won't be automatically overwritten on update) > devs don't like packaging for every distro under the sun source .deb will generally works fine under Ubuntu, Debian and most flavours just fine unless you have some funky dependencies (and if you do, installer will also be complex) RHEL/Centos RPM will cover near-whole rest of the market. MacOS/FreeBSD will be different enough anyway that you will need to write a bunch more in install script Building simple package that just delivers binary is not even that complicated. Getting them to pass distro muster is often harder but you don't need to do that. > Package managers are great... for the user. For everyone else, a polyglot system, with arcane technical policies, and even more arcane human policies is... not ideal. Most of those "arcane" policies are there so random incompetent dev won't fuck up other stuff in the system. Which is also why users want packages in the first place. And you don't need to abide to any policy to make simple package that just puts your files on the system. Building dumb debian package is just few metadata files (post/preinst scripts + a file describing your package) in a directory and a single command. You only need to worry about policies if you want to submit package to distro, and there are in place for a reason. No shit they are better for users, that's their entire fucking point!

mustache_kimono 4y ago
> No shit they are better for users, that's their entire fucking point! I'm not even sure we disagree about anything, and you're yelling? FWIW I package and distribute my software but for a long time I didn't. My position is very simple -- it's always easier if someone else does the work for you. If someone chooses not to distribute with a package, that's fine. If it bothers you, the choice is to build a package spec and pipeline for that project, not to moan about it. But packages are not an entitlement of a non-paying user. That user is perfectly entitled not to use your software, because complaining about the packages you may or may not have available is stupid, and not the devs problem.