Re: dpkg flex-based status file parser, for 35% speedup
Guillem Jover writes ("Re: dpkg flex-based status file parser, for 35% speedup"):
> I don't see the point in merging it back, to have to undo that later
> on. I think it's way better if we use this as an excuse to actually
> start moving towards a proper libdpkg, we might have to start some
> day anyway.
It's not very hard.
> I've just prepared a patch which switches the library to be shared
> one (I'm missing adding a version script), for now we'd only provide
> libdpkg0 (and probably libdpkg0-dbg), and no libdpkg-dev, as the lib
> should be considered private as it is now.
That's not correct. The problem is that since libdpkg has no stable
ABI, it is not safe to mix /usr/bin/dpkg from one version of dpkg.deb
with your /usr/lib/libdpkg.so from another. If dpkg were interrupted
halfway through updating itself, the system might be irrecoverably
broken.
> At the same time this rises the question of the static linking
> against zlib, libbz2 and libselinux, I've switched those to dynamic
> linking in the patch, as I don't think the current situation makes
> much sense. We'd need PIC versions otherwise, it's a pain for security
> reasons (#317967), if the system gets into a state that dynamic linking
> does not work, you have probably worse problems than dpkg not working,
> and we rely on other essential packages linking against some of these
> libs (zlib and libselinux). Also the 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 ?
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.
Ian.
Reply to: