[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Tutorial #2: using dpkg in user space



> 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...



Reply to: