On Tue, Oct 12, 2010 at 12:25:53PM -0500, Jon Ciesla wrote:
My understanding is that to completely unbundle a library, whether a
solib, a PHP lib, a Python module, whatever, you need to remove it from
the upstream tarball prior to the build (i.e. modified tarball, not a
patch or rm -rf in prep),
This part at least is not necessary. We only modify the upstream tarball
when there's a reason that we can't ship the upstream source (which does
coincide with bundling of some patent-encumbered media libraries.)
and then use flags, symlinks, or whatever is
appropriate to use the system lib for building and running the program.
I don't feel like including the bundled version and making sure it's not
used is enough. You *can't* really make sure it's not used if it's present.
<nod> This is the part I'd like us to discuss and decide. With pure
python
code, I can audit a particular release fairly confidently but in many cases,
that doesn't provide protection when the next release is made (as upstream
may have made a mistake when importing the compat library in their new
code). Scons is an interesting case in that they've done a very good job of
making it so that won't happen either.
I'm not sure about whether that's possible for other languages and also
whether we want to ignore the technical possibilities in order to make it
easier to review -- ie: "Just delete the bundled versions and patch the
source code so it runs" is easier to test if you're a non-programmer than
"you don't have to delete the bundled version if certain other technical
requirements for marking the library private are met of which both the
reviewer and the packager would have to be knowledgable".
-Toshio