> Unfortunately, my hopes have been dashed. I now realize that dpkg has > only ever aspired to be "throw away code", so I should look elsewhere
Tsk, tsk. Not all custom applications are throwaway, even though the "unix philosophy" might indicate that. Sometimes, as in this case, they actually solve a *particular* problem well, instead of being hints and building blocks... sometimes you want a collection of panels, wires, and tubing, and sometimes you want a car :-) I think it's probably a fair generalization that the better a program (or tool) is for solving a specific problem, the less value it has for other applications, and dpkg is simply fairly high on the specific side of the scale. > A src-orig-*.deb file is a simple wrapper for the tarballs + any extra > information you want to add to the description. It would be possible > to wrap one around a tarball with a single command. There would be no > possibilities for errors. Point of information: there are *lots* of possibilities for errors. Syntax of the description file; running out of disk space (in this dir? in /tmp? where else?) during the construction. Just because it's a single command doesn't make it "safe" -- it's still a complex operation. Also, in another post you mention a few additional things you could do with something like this. It appears that you still disagree that package-building is *not* a system function, but a user function. If anything, a tool to keep track of a pool of source packages in my homedir might be interesting -- and one could certainly consider lessons learned from dpkg about some of the details -- but because it's "tuned" for the problem of integrating packages into the system, I'd say it's less suited for what is really the opposite problem. Remember that the unix filesystem *itself* is one of these generic tools; it is the unix-ish way of organizing files; and forcing stuff into system directories just because some tool does that seems like a tail-wagging-the-dog design choice...
