On 8 October 2015 at 23:58, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > Matthew Miller wrote: >> In many cases, this effectively means creating a Fedora-specfic fork of >> the project. > > Only if you call patches to the build system (with little to no changes to > the actual code) a "fork". > >> Even if we accept unbundling as goal in itself is a given, there just >> aren't enough people in the world who have the inclination, time, and >> expertise to do this. Especially when you consider that for most projects, >> the only people with *deep* understanding of this kind of invasive change >> *are* the upstream. > > Huh? 3 simple steps to unbundling (>90% success rate, especially with the > growing number of stupid upstreams that bundle not out of necessity, but > because they simply don't believe in unbundling): > 1. rm -rf the bundled library (in %prep, or rip it out of the tarball > entirely if there is any chance of a licensing issue of any kind), > 2. Remove the building of the bundled library from the build system and add > the required -I and -l flags instead. > 3. Check the source code for hardcoded relative > #include "../3rdparty/foo/bar.h" paths and fix them to use proper > #include <bar.h> or #include <foo/bar.h> paths (depending on the library, > read its documentation). (If the code already uses the correct path > style, there is nothing to do.) > 4. Take over responsibility for keeping the application up to date with Fedora's version of the library. I'm actually all for unbundling, but going it alone is not guaranteed to be simple. "Oh, hey, that deprecated function has been removed." -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
