[Greg Stein]
> We chose to allow options other than amalgamation because we'd heard
> feedback, "let the sysadmins upgrade sqlite independently on their
> system", rather than pinning svn to whatever-we-shipped. IOW, if we
> ship an amalgamation, then it becomes *our problem* when bugs appear
> in sqlite, and we need to spin up a new release.
Yes, and this choice is valuable. In Debian, we learned our lesson
about redundant copies of library code in our binaries. It used to be
quite common for projects to copy zlib code into their own projects
... until a potential security bug was found in it. For weeks
afterwards, the Debian Security Team was patching random packages and
releasing advisories for them. Not much fun for them, I think.
Some years later, the same thing happened with xpdf, another popular
codebase to copy and paste. So these days, we're pretty strict about
_not_ embedding library code into our binaries, unless the code really
is specific to the one project.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2009-05-04 22:32:08 CEST