"Why Linux Sucks" and "Why Linux Does Not Suck" videos from Linux Fest

There are a few issues with code duplication, but at least it never breaks.

1. Because that puts extra work on the developers who don't necessarily know the target system very well. What if the developer doesn't know the FHS (which apparently is quite common, given what I've seen...)? How are you going to manage dependencies if the packaging systems differ widely (and no, there's no one way to bridge them all, because some of them differ because of the whole construction of the distribution itself!).

2. They'll never do it.

(#1 leads to #2, but seriously, it's enough work getting developers to write a proper Makefile/gemfile/setup.py or whatever is appropriate for the language they're working in. Now you want them to do it 100 times over, for systems that they've probably never used before?)

That works for something like sta.li, in which everything is statically linked, because then you have no problem. But when you start talking about dependency tracking and small-but-important configuration differences between distributions, this becomes impossible.

The solution is to use a two-tiered approach, which some distributions sort of already do. If I make a Python program, for example, I create a setup.py file and all of the other things that you need to install it with pip (sidenote: this is embarassingly complicated for a language that's dead-simple otherwise!). Then, I let each distro's community handle it themselves - after all, they know their system better than I do, and remember that I've already listed all dependencies, etc. because I've packaged the program itself properly!

Then, the distribution can figure out how to handle those packages - perhaps installing them directly through pip is the best solution, or perhaps they add an extra layer the language-specific package (check out the AUR for something similar to this), or perhaps they want to just hard-code the file destinations. Whatever makes the most sense in the context of the distribution itself.

And note that Android's (which I assume is what you're referring to when you talk about "app bundles") middleware packaging is no less complicated (honestly it's a lot more so in a lot of ways -- no firm dependency tracking, everything must build all at once). Check the AOSP "external" tree.

Then you have software that doesn't have official releases (like half the stuff on github)

I'll stop using a package manager the day that all ruby gems work with MRI 1.8, 1.9, JRuby and REE. Basically, never.

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.