> or the needs of software packagers.

They address the needs of users.

I don't care about software packagers at all, except insofar as they can address the needs of users.

> The solution to having inconsistent packaging paths isn't to introduce _yet another_ packaging path system, but this one specific to djb stuff. It's to use a standard build system with overrideable paths, and not to assume the author knows better than the packager.

Having "inconsistent packaging paths" isn't the problem. The problem is I have a program called "foo" and I don't know if it should begin with:

    #!/usr/local/bin/python

or:

    #!/usr/bin/python

Somebody who doesn't have a real job made the joke that it should "obviously" use "overridable paths" like this:

    #!/usr/bin/env python

but that person hasn't used very many unix systems so they're unaware that this doesn't work on some systems. Eventually the "package manager" compromised with:

    #!/bin/sh
    ''':'
    if type python2 >/dev/null 2>/dev/null; then
      exec python2 "$0" "$@"
    else
      exec python "$0" "$@"
    fi
    '''

And users are like "what the fuck!?" All we needed to agree was that python "lives" in /usr/local/bin/python and python3 (an incompatible alternative to python) lives someplace else, we would have been fine.

And for what? Why did we bother with this? What did we actually gain for all this extra shit? Some package manager felt like he was doing the job of a tarball?

> They don't address cross-compilation at all, or the needs of software packagers.

Cross-compilation is tricky for programs that need to run programs to figure out how they need to be built; neither cmake or GNU autoconf do anything to address it.

The best solution package managers seem to suggest is to "not do that" but those programs are slow.