[Fedora-packaging] Re: Use of Internal Libraries

[Toshio Kuratomi]

Axel Thimm wrote:
> 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.
> 
Upstream is wrong.  The consequences of their actions don't come back to
haunt them, though, they come back to haunt us.  If there's a security
hole in their library snapshot, their answer can be "we fixed that two
months ago.  Why didn't you update?"  Our answer would have to be: "We
have an unfixed vulnerability in gnome-foo-player, toms-foo-player, and
foo-plus-player.  We are not able to fix these until we perform a port
to an incompatible ffmpeg snapshot for the maintainers of the affected
software."

>>> 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 think there is benefit:
1) If the library is statically linked in the application it's harder to
find in a quick audit.

2) If the flaw affects a range of library versions (for instance,
899.x.y is unaffected), having them be packaged separately makes finding
the affected versions and fixing them easier than finding out which
versions of the private library each app has.

Also, one of the goals of a distribution is to make programs and
libraries work together.  So the approach we'd likely want to take is
choosing a few versions of the library that we could support (probably
in conjunction with other distros) and then porting the apps to one of
those library versions and getting upstreams to update their private
libs to those versions since we were willing to do the port for them.

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

I am against this approach.  But perhaps you'll have a useful counter to
 the points I raised.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20080919/7dae01d2/attachment.sig>