[Fedora-packaging] Re: Use of Internal Libraries

[Axel Thimm]

On Fri, Sep 19, 2008 at 02:56:25PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 19 September 2008 at 09:34, 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?
> [...]
> > 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.
> 
> I don't know if you've been following FFmpeg development lately, but
> they have improved over the last year or so to the point that no ABI
> breakage occurs

Note I mentioned the API, which is still changing on a regular
basis. For ffmpeg it doesn't actually help that there are no releases
ever either.

> without bumping the major version of the affected library. The
> pkg-config support is put properly in place, too, so if you haven't
> done that already, it's high time to begin convincing depdendent
> projects to start supporting shared FFmpeg. I've already begun
> working on fixing the main consumer of FFmpeg, MPlayer, to do that.

Unless ffmpeg actually releases anything again I doubt that too many
projects will try to depend on an external shared lib whose API
stability window is a few weeks.

This is not a criticism against the very nice work of the ffmpeg
people. They just need the freedom of a non stable API for being able
to develop as fast and take into account that projects need to cut a
snapshot (actually they enforce this explicitely).
-- 
Axel.Thimm at ATrpms.net