[packman] [opensuse-factory] Fwd: commit libavutil for openSUSE:Factory

[Dave Plater]

When I discovered that the future xine-lib had a hard dependancy on
libavutil and that libavutil wasn't encumbered by patent problems
(August last year) I decided on a static lib built with xine due to
libavutil being part of ffmpeg.
The only safe way that I can see with a dynamic libavutil in factory
is for packman to also separate libavutil and  build a linked package
otherwise it will be a problem to keep them in sync. The Packman
ffmpeg maintainer will need to maintain openSUSE libavutil as well. I
normally run multimedia:apps with libxine-codecs from Packman. Ffmpeg
tends to change frequently and may cause unforseen problems if
libavutil gets out of sync. libxine2 itself needs libavutil the rest
of the ffmpeg libs  are used by plugin builds. IMHO the xine-lib
developers should include a static libavutil. Have a look at Debian
and Fedora for clues.
Excuse the gmail top posting.
Dave

On 6/24/12, Cristian Morales Vega <reddwarf at opensuse.org> wrote:
> If xine is going to be the only library that uses libavutil a static
> version could make sense. But there is no reason to think that's going
> to be the case. And then... really, I fail to see the problem here.
> Could you please show a specific case where using a dynamic version of
> libavutil there is a problem that isn't there when using a static one?
>
>
> On 24 June 2012 13:47, Dave Plater <davejplater at gmail.com> wrote:
>> I have been working on a static build of libavutil included in the hg
>> version of xine-lib but was having difficulty getting that version of
>> xine-lib to build. Unfortunately I'm computerless atm but this would
>> certainly solve the problem.
>> Dave
>>
>> On 6/15/12, Cristian Morales Vega <reddwarf at opensuse.org> wrote:
>>> On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar
>>> <DimStar at opensuse.org> wrote:
>>>> Has this be well planned
>>>
>>> Since xine 1.2.x depends on libavutil unconditionally
>>> (https://bugzilla.novell.com/show_bug.cgi?id=762784) it's basically
>>> the only solution.
>>>
>>> But I don't see any real problem here. Can you put an specific
>>> combination of circumstances that would be problematic? It would be
>>> safer and easier if libavutil versioned symbols in a more detailed way
>>> instead of just to avoid using symbols from a library with a different
>>> soname, but that problem happens with lots of libraries that don't
>>> even version symbols at all.
>>> xine is the only package from openSUSE that will link against it. And
>>> the most common case is for users to use both xine and libavutil from
>>> Packman. So this seems 100% safe to me.
>>>
>>> _______________________________________________
>>> Packman mailing list
>>> Packman at links2linux.de
>>> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>>>
>
> _______________________________________________
> Packman mailing list
> Packman at links2linux.de
> http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
>