Uniting to get upstreams to use system libraries

[Patrice Dumas]

On Fri, Sep 19, 2008 at 11:04:16AM +0100, Colin Guthrie wrote:
> 
> Other programs (one example being MythTV) make some significant changes 
> to their libraries (ffmpeg) and/or use their own version to cut down on 
> the external dependencies. For me dependences are our job, and 
> application developers should not worry about that, but this opinion 
> simply wont float in the MythTV community where the devs have come under 
> some flack for the number of external dependencies they require and the 
> difficulties users have in building it. Changing the minds of MythTV 
> will be pretty hard. This is just an example of a project I am familiar 
> with, I'm sure other projects that do similar things will have their own 
> reasons too.

It is perfectly understandable to have upstream ship some libraries,
even prebuilt, to help users, especially on platforms where dependencies
are not packaged. However it should be possible to use system libraries
instead, maybe based on a configure flag, on a build config variable
somewhere, or whether the internal library directory is there or has
been removed. This may entail some work to be able to have both ways of
building, but I have never found upstream rejecting (in the long run)
such changes, as long as they are done in upstream style.

A more problematic issue is when the internal libraries are patched. I
can't see an easy way to workaround this issue, indeed this amounts to a
fork, and I can't see an easy way to avoid forks when an upstream cannot
agree with the original project.

--
Pat