The history of dpkg is really interesting, it has its roots in a a biologist trying to avoid ripping his hair out with dependencies so he wrote "StopAlop" (
http://www.verycomputer.com/195_d4343843af185e14_1.htm). A few months after he posted it others took on the task of porting it to a more robust shell script which was eventually re-written into C, and slowly evolving into what we have today.
What's more interesting is that a lot of package managers for programming language package managers use (or used) the fundamental concepts in dpkg. For example, for a long long time Composer (the thing that saved PHP from death) was a re-implementation of some parts of dpkg with a language-specific world view. I don't know for sure about others but I think this is also true for NPM, pip and ruby gems.
Something else that I think about a lot: the industry spends a lot of CPU cycles to compute the suitable dependencies, but there are several alternative ways to solve dependencies. But those alternatives don't generate interest because the StopAlop lineage is so built in to how we work on software it almost goes unnoticed as a natural law of the world like gravity, so there's no prompt to directly challenge it.