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
Attachment:
pgpTo1uLBfclS.pgp
Description: PGP signature
-- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
