On Fri, Sep 19, 2008 at 09:59:42AM +0200, Ralf Corsepius wrote: > > I'd ask the question differently: If upstream saw itself forced to > > duplicate/fork a lib how can you help making the forked bits back into > > the original upstream. > Then let me answer with my "developer's hat" on: > > The reason why such "forks" exist, often is disagreement between > "upstream" and "fork" devs, because they disagree on APIs/usage and the > like. > > Upstreams often accuse "fork devs" to be abusing their libraries/APIs > (e.g. using undocumented internals). Conversely, "fork devs" often > accuse "upstreams" not to listen to "users' demands". > > I.e. in many cases such conflicts will hardly be resolvable. Yes, and sometimes as in the case of ffmpeg and minilzo upstream even wants you to take a snapshot, e.g. the "forking" is in their consent. > > Just to quote one such example: ffmpeg is a fast moving target, and > > any project depending on the lib API is cutting a checkout, patching > > it a up and using it for its own purposes. Replacing these internal > > ffmpegs with a system ffmpeg is a nightmare or even impossible w/o > > rewriting the app interface to it. Given that ffmpeg and friends fall > > under the patent forbidden class we don't see that directly in Fedora, > > but this issue is still out there. > Well, ffmpeg is a special case wrt. many issues. If they were doing a > proper job, they would release properly versioned packages with properly > versioned APIs, which could be installed in parallel. Even if so, would Fedora package 20 different versions of ffmpeg to satisfy the 20 different consumers? There wouldn't be any benefits to an internal lib either: If there is a security flaw fixed in ffmpeg 1004.0.1 the versions 900.x.y to 1003.x.y would be just as insecure as external packages. > > I'd recommend to soften this guideline to something as "the packager > > should try hard to use system libs, and try to communicate the > > benefits to upstream, but if there are reasons not to use system libs, > > then he should document this in the specfile". > I am not sure this is a good idea. I'd rather be stricter on this, > because this would force devs to think about what they are doing and > packagers think about the quality of what they are packaging. > > The unpleasant truth is: If a package bundles "modified libs/apps" from > elsewhere, which can't be installed in parallel to the original > libs/apps, this package's dev's are doing something wrong. The truth is that sometimes upstream makes some decisions, we can try to forward our position, but upstream may ignore us or maybe will have a good reason to counter our position (for ffmpeg and minilzo I believe upstream is correct and we should be the ones revising the guidelines). That's why I suggest that the packager tries hard to do it in the typical shared way, but if there are sane reasons to use internal libs to not let the package dry out forever in some review queue like for x11vnc. -- Axel.Thimm at ATrpms.net -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
