6 ms·

> Added to that are the package managers reliance on specific OS constructs. Homebrew works but we really shouldn't have to use different package managers just

> Added to that are the package managers reliance on specific OS constructs. Homebrew works but we really shouldn't have to use different package managers just because we're on a different operating system. Either the package supports that OS or it doesn't, but this shouldn't say anything about the package manager. I don't really follow your logic. There are very good reasons why you wouldn't be able to install the same package in the same way on Linux and OS X. (For starters, homebrew isn't true package manager in that it's not a one-stop shop - it can't even handle critical system updates like apt-get/pacman can!) > Aside from all of this is the difficulty in actually constructing the packages. Arch PKGBUILDs seem the closest I've used to an easy source->binary package but they're not mainstream. As far as I know debs still don't support natively bundling the source with the binaries and the RPM SPEC system is the single unfriendliest system I've encountered to quickly make a portable package. I think PKGBUILDs are the best of both worlds, because they allow system-specific package management to coexist with application-level packaging - two related, but subtly different problems. PKGBUILDs are general-purpose enough that they can do pretty much whatever you need them to do, assuming that they're well-written (which is our assumption when comparing any packaging method), and they're flexible enough that you can modify them to fit your specific system. The only real problem I see with PKGBUILDs is that, at least on Arch, they're community-developed, which means that they can be out-of-date or variable in quality. But that's no worse than the situation if you were to install from source, anyway (which is the alternative), and that's more a byproduct of the way that the Arch community is structured than the PKGBUILD system itself. I'm sure if Red Hat or Canonical suddenly decided overnight that they'd start supporting PKGBUILDs, things would be different (and would have their own problems, likely...) > Moreover, the ties to shell script just continue to harm OS independent adoption Without looking, I'm 99% sure that PKGBUILDs are bash, not sh, but I'm also 99% sure that 99% of the PKGBUILDs I've ever installed are sh-compatible. And I don't think that's the worst thing in the world - in this day and age, you have to be able to handle sh for any Unix-like OS, and you have to be ready to implement the appropriate interface for any other OS that you want to be compatible (or to throw compatibility to the wind altogether, like Windows does). Second, since many PKGBUILDs are really just convenient wrappers around the already-provided application distribution mechanism, I don't see how this is that bad at all.

Locke1689 15y ago
I don't really follow your logic. There are very good reasons why you wouldn't be able to install the same package in the same way on Linux and OS X. (For starters, homebrew isn't true package manager in that it's not a one-stop shop - it can't even handle critical system updates like apt-get/pacman can!) I'm arguing that we should have an OS switch in the same way we have an architecture switch. If we assume that our PM can handle application packages as well as system packages then we should also be able to use it to install application packages on any OS which support it. For example, python should be installable on everything from Windows to BSD all using the same "pm install python" command. Packages will be marked as explicitly supporting OSes. I think PKGBUILDs are the best of both worlds, because they allow system-specific package management to coexist with application-level packaging - two related, but subtly different problems. PKGBUILDs are general-purpose enough that they can do pretty much whatever you need them to do, assuming that they're well-written (which is our assumption when comparing any packaging method), and they're flexible enough that you can modify them to fit your specific system. The only real problem I see with PKGBUILDs is that, at least on Arch, they're community-developed, which means that they can be out-of-date or variable in quality. But that's no worse than the situation if you were to install from source, anyway (which is the alternative), and that's more a byproduct of the way that the Arch community is structured than the PKGBUILD system itself. I'm sure if Red Hat or Canonical suddenly decided overnight that they'd start supporting PKGBUILDs, things would be different (and would have their own problems, likely...) Agreed. Without looking, I'm 99% sure that PKGBUILDs are bash, not sh, but I'm also 99% sure that 99% of the PKGBUILDs I've ever installed are sh-compatible. And I don't think that's the worst thing in the world - in this day and age, you have to be able to handle sh for any Unix-like OS, and you have to be ready to implement the appropriate interface for any other OS that you want to be compatible (or to throw compatibility to the wind altogether, like Windows does). Second, since many PKGBUILDs are really just convenient wrappers around the already-provided application distribution mechanism, I don't see how this is that bad at all. This was my main complaint with PKGBUILDs. A bash/sh dependency hurts on non-Unix OSes. I'd rather Python than sh. I also admit that, for the most part, I absolutely hate sh and all its derivates and view them all as dirty hacks, so this is probably just innate bias.
- 15y ago

Locke1689 15y ago

I don't really follow your logic. There are very good reasons why you wouldn't be able to install the same package in the same way on Linux and OS X. (For starters, homebrew isn't true package manager in that it's not a one-stop shop - it can't even handle critical system updates like apt-get/pacman can!) I'm arguing that we should have an OS switch in the same way we have an architecture switch. If we assume that our PM can handle application packages as well as system packages then we should also be able to use it to install application packages on any OS which support it. For example, python should be installable on everything from Windows to BSD all using the same "pm install python" command. Packages will be marked as explicitly supporting OSes. I think PKGBUILDs are the best of both worlds, because they allow system-specific package management to coexist with application-level packaging - two related, but subtly different problems. PKGBUILDs are general-purpose enough that they can do pretty much whatever you need them to do, assuming that they're well-written (which is our assumption when comparing any packaging method), and they're flexible enough that you can modify them to fit your specific system. The only real problem I see with PKGBUILDs is that, at least on Arch, they're community-developed, which means that they can be out-of-date or variable in quality. But that's no worse than the situation if you were to install from source, anyway (which is the alternative), and that's more a byproduct of the way that the Arch community is structured than the PKGBUILD system itself. I'm sure if Red Hat or Canonical suddenly decided overnight that they'd start supporting PKGBUILDs, things would be different (and would have their own problems, likely...) Agreed. Without looking, I'm 99% sure that PKGBUILDs are bash, not sh, but I'm also 99% sure that 99% of the PKGBUILDs I've ever installed are sh-compatible. And I don't think that's the worst thing in the world - in this day and age, you have to be able to handle sh for any Unix-like OS, and you have to be ready to implement the appropriate interface for any other OS that you want to be compatible (or to throw compatibility to the wind altogether, like Windows does). Second, since many PKGBUILDs are really just convenient wrappers around the already-provided application distribution mechanism, I don't see how this is that bad at all. This was my main complaint with PKGBUILDs. A bash/sh dependency hurts on non-Unix OSes. I'd rather Python than sh. I also admit that, for the most part, I absolutely hate sh and all its derivates and view them all as dirty hacks, so this is probably just innate bias.

15y ago