On Thu, Dec 28, 2000 at 05:39:04PM -0600, Adam Heath wrote: > > Not quite. dpkg-deb actually does call out to tar and gzip, and lets those > > programs do what they do best. It doesn't try to be tar and gzip and dpkg > > all > > at once. The UNIX approach is to build tools that do one or a few jobs very > > well, and build larger tools out of that code base. That way, once a > > problem > > is solved, it is solved for all programs that share the problem-solving > > code. > > Well, see, dpkg 1.8 in incoming no longer calls an external gzip binary(note: > this is a configure option). It is linked to zlib statically. This gives a > small speedup.
Same idea, different implementation. It is using (de)compression code that is shared with other programs. > In dpkg cvs(what will be 1.9), dpkg no longer calls an external md5sum(it also > doesn't fork for it, which it still does for the gzip above). This isn't as > bad, because it already had it's own internal md5sum binary, I just moved the > code into the internal library it uses. Will we one day see a shared libdpkg, with more code moved into it, so that we don't have to fork and call dpkg to do, e.g., version comparisons and extraction of control file information? -- - mdz