Nico Golde writes ("Re: Bits from the Testing Security team"):
> quoting Adam Heath from #debian-devel:Thanks for passing that on. > 2007-10-15 18:07 <eigood> dpkg's configure has an option for using > shared libraries or static linking > 2007-10-15 18:08 <eigood> for gzip, it can do a static library link, > a dynamic library link, or a runtime > fork/exec of gzip > 2007-10-15 18:08 <eigood> afaicr, when I did the patch > 2007-10-15 18:10 <eigood> the real reason, is dpkg used to only > fork/exec gzip > 2007-10-15 18:11 <eigood> for efficiency, I gave it an option to > link to zlib This reason doesn't make sense because it's not more efficient. It saves about two fork/execs per package, which is not a significant part of dpkg's execution cost. Indeed on modern multicore systems running the decompression in a separate process allows it to be run on a separate CPU, in parallel to the other processing done by dpkg proper. So it might be faster. (I haven't done any benchmarking but I think these conclusions are pretty obvious.) Scott James Remnant has said that statically linking the compression libraries into dpkg was done for robustness. This makes more sense but I disagree with this approach. There are numerous things on the system that dpkg depends on working properly, and without which you can be hosed - starting with the kernel and libc and working upwards. Binding all of these things statically into dpkg somehow would be madness, and there is no particular reason why compression libraries are special. On the contrary there are a few reasons to bind decompressors in particular more losely: it is useful to be able to change the set of available decompressors (for both experiments and future extensions), and decompressors tend to have occasional security problems which make them vulnerable to their input and which therefore require rebuilds of all packages which statically link agains them. Having dpkg invoke the decompresser as a separate program provides several IMO important advantages. It simplifies the code in dpkg, and it greatly simplifies the management of cross-version compatibility and multiple optional decompression schemes (including experimental ones), by decoupling dpkg from the decompressers. It simplifies the management of the dpkg source package (since it loses those build-dependencies), avoids worry about security updates for decompresser bugs, etc. > 2007-10-15 18:11 <eigood> however, I didn't want to introduce > another dependency into the base system > 2007-10-15 18:11 <eigood> so I made it link statically I think this would be misguided even if the premise (that the library isn't included in some other bit of the base system) were true. The purpose of removing dependencies from the base system is to try to shrink the base system; this purpose is frustrated rather than achieved by bundling copies of things into base packages. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
