Re: dpkg flex-based status file parser, for 35% speedup
31-08-2007, Bruce Sass
> On Fri August 31 2007 07:54:51 am Ian Jackson wrote:
>> > addition of libbz2 as pseudo-essential should not be a big deal,
>> > it's quite small, and most of the code is duped already due to it
>> > being statically linked.
>>
>> Why are we not using external programs for this ? Does anyone know ?
>
> So the package handling system doesn't stand to break because of a bug
> in one of them?
>
>> Using external programs simplifies dpkg's build process, makes tuning
>> particular installations easier, makes better use of multiple CPUs,
>> and generally seems superior in almost every respect.
>
> except robustness, imo
Why gzip/bzip2/ar should become broken suddenly?
Only due to broken installation of one's package.
I tried to use broken down dpkg-deb logic for geloiwa, but installation
process revealed that brokenness. The libc upgrade hurts the most,
especially when old programs are segfaulting on new libc, despite of
using all-old symbols and their versions.
I also do think, that normal tool-for-thing thing wrapped in the reliable
sh script is a good thing.
The dpkg-deb must be static if binary, as tools inside shell version
period. OTOH linking shell like dash statically is another question :)
____
Reply to: