The file path (which includes directory names) is indeed meant to be useful to a human, for very good reasons.

All [modern] packages have unique names without the need for a completely unique identifier embedded in the file name. The file name is guaranteed to be unique by the distribution maintainer of said package. Usually for 3rd-party packages a postfix of a revision number and the distribution from whence it came is what makes it unique for that distributor. This ends up not only giving you insight as from whence the package came in the name, but which revision it is (if listing them sequentially, for example).

But it isn't package names that need to be unique, it's file paths delivered by the packages, and that certainly is a useful thing that's good to solve with a package manager. But you still need to be able to discern with your eyes what is what! You can't easily do that by comparing a gigantic SHA hash between two file paths, but you could do that if the difference between each other was very minor, but indicated what each path actually was related to (in terms of version, arch, revision, order of installation, or any other number of criteria).

I get it - you're trying to support a completely universal, will-never-conflict file path. But we don't need that!!! It's simple to maintain a small, mostly-collision-free postfix to a package name that is both human readable and fairly unique.

Another way to point out the ridiculousness of the hash-in-file-path system is in your first paragraph:

> It's not like relational data stores use human readable primary key fields is it?

File paths are not relational data stores. File paths are a human interface. A program can store and retrieve data in any way it chooses, and in much more efficient forms than filesystem paths that use "special character" separators, are subject to various environment changes, language specifics, platform differences, and name length limitations. We use file paths because they're the easiest way for humans to organize data files on the disk. Hell, their inherent crappiness is part of why many applications have to be built to "scale" how they manage files to get around the inherent problems of human-readable file paths. Sticking a grotesque amount of non-human-readable metadata in there is like trying to shove a calculator into a pencil.

> The hash serves another useful purpose anyway - the ability to verify a package.

What the hell is this doing in the file name, though? Packages already include hashes of themselves and their files. You can verify any of them with the record they create in the package management database, or in the original package.

I don't get what your point is about people "lying" about the binary package or inserting malware. We've had public key-signed packages for decades. This is a non-issue.

Config management is completely different from package management. I know there are systems out there that try to build in hooks so you can use one from the other, and i'm not saying it's completely useless. But in general it's crap to try to do the functions of one tool in another tool. They need to exist independently for obvious management reasons. The more you tie them together, the more of a maintenance headache you are left with.

Lastly, i'll just say that my favorite Linux distribution (in terms of stability, reliability, etc) is Slackware. It basically defies all of the reasons Nix seems to exist for, yet it works beautifully in spite of it. It turns out that you don't have to wrestle and fight with your packages to make a system work well.