> You are forgetting that when you run dpkg-source -x, it copies a > .orig.tar.gz file to your directory. So there is no difference in > disk space used.
Disk space wasn't the point -- just actual steps of work involved (and by steps I mean "points of failure" as well, ie. more automation does *not* replace simplifying the problem...) and that the two steps of "dpkg -i src.dep; make ... unpack" were exact replacements for "wget mirror:src*; dpkg-source -x src.dsc" [ignoring the additional bookkeeping of course -- partially because it doesn't make anything we currently do the old way easier, again ignoring the use of source dependencies.] > A stone age attitude, if you ask me. I can think of lots of cool, > never-attempted-before applications that would benefit greatly from Umm, then perhaps you *should* think of them, and tell the rest of us. I'd rather we first solved the problems we're having now, than inventing new and exciting problems :-) Remember that one of the problems we're having is that package building is *complicated*. That's partially why rpm keeps getting mentioned; for well formed packages, you grab the spec file (*not* the srpm) and do rpm -ba, and you're done (since rpm sucks down the tar files directly from the upstream source, at least in theory.) I don't know that *that* is actually a goal, but it's a good argument against adding *more* bookkeeping/bureaucracy to a package build. > This is a philosophical difference. I think dpkg could be very useful in > user space for "channels" of information, sources, and a whole gamut Sure -- but one has to be *very* careful to remember that the real users actually use the machine to do *work*. Organizing for organization's sake is a seductive trap (been there, done that.) Remember that while debian does cater particularly to software-hacking users (because (1) that's what free software is all about (2) they're a lot like us, so we understand them) they aren't the whole universe or even, I suspect, a majority of the debian users.
