[Fedora-packaging] Re: Use of Internal Libraries

[Ralf Corsepius]

On Fri, 2008-09-19 at 10:34 +0300, Axel Thimm wrote:
> On Fri, Sep 19, 2008 at 01:41:50AM +1200, Nigel Jones wrote:
> > So I know we have
> > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries
> > which I think is pretty good, easy to understand and fairly simple.
> > 
> > The problem I think is that some upstream's still want to ship
> > internal, modified libraries.
> 
> > Upstream says "it's a guideline not a rule".
> > 
> > _MY_ question is, what can we (Fedora) do to make it clear that we have
> > clear cut rules for why we don't want packages providing internal
> > libraries?
> 
> 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.

> 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.

> 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.

Ralf