Previously I went on at length about the flaws in the language-based package manager model; coincidentally I got to see some of the background/sausage-making1 of a Debian attempt to reconcile certain pip vs. dpkg issues. While I have a lot of respect for the people involved and the effort they're putting in to the problem, I stood (quietly) by my belief that the whole space is wrong... and then a digression about C led someone2 to state that
it could be argued that distros packaging is the C package manager
which collided with a few other ideas floating around in my head:
relatimestory specifically, as an instance of a solution that implies a class of approaches.)
All of this clicked into shape as a pattern of privilege - not to coopt the language of the very real problems the industry faces, but just to look at the "anti-pattern" of the conflict between distro and language package management from a perspective that makes some sense of why language package managers refuse to die off - it's not just that the people who work on them are persistent and/or stubborn. Certainly it turns the question around: given all the other language-specific package managers, where is the C one? And, as with social privilege, once you start looking for it, you realize that maybe "you're soaking in it" - and that Unix has been, since the 1970's, an extended support system for the C language, so of course any "distro packaging system" is going to be heavily C-program biased.
Now is that a helpful epiphany? It has the initial smell of "reduced to a previously unsolved problem", but it does suggest that attempting to credit C with it's proper share of the packaging burden might be productive; that leads to the idea that instead of "why would a language have anything intelligent to say about where files get installed" that in fact, the language may have one set of things to say, and the distro has a different set of things to say, and while we need them to mesh, they are more likely (today) to grind. It also suggests the fun mental exercise of considering a world, perhaps not without C but one where you assume your language of choice (yes, Python) as a starting point - maybe not as deeply special as the Lisp Machine, but it could still lead to some implementable insight.