[opensuse-factory] Fwd: commit libavutil for openSUSE:Factory
Hi everybody! Small topic I would like to raise awareness for (in best case it's only to have it documented): ----- Forwarded message from root@suse.de ----- Date: Fri, 15 Jun 2012 16:31:34 +0200 From: root@suse.de Subject: commit libavutil for openSUSE:Factory To: opensuse-commit@opensuse.org Hello community, here is the log from the commit of package libavutil for openSUSE:Factory checked in at 2012-06-15 15:41:42 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/libavutil (Old) and /work/SRC/openSUSE:Factory/.libavutil.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Package is "libavutil", Maintainer is "" Changes: -------- --- /work/SRC/openSUSE:Factory/libavutil/libavutil.changes 2012-06-13 13:31:48.000000000 +0200 +++ /work/SRC/openSUSE:Factory/.libavutil.new/libavutil.changes 2012-06-15 16:31:33.000000000 +0200 @@ -1,0 +2,5 @@ +Fri Jun 15 04:03:15 UTC 2012 - factory-maintainer@kulow.org + +- add -32bit library for xine to use + +------------------------------------------------------------------- So, that means we now do have libavutil in Factory? Has this be well planned and the side effects are well known? Especially be aware that PackMan and VLC Repo both carry this library as part of the ffmpeg builds. frankly, I'm *scared* of side effects being introduced here: PM / VLC will likely move to 'more recent' (or just 'different') versions of ffmpeg in no time. having libavutil now part of Factory will make it VERY likely to cause issues on all kind of applications coming from those repos; an updated ffmpeg in any of those repos will need to be SURE it gets libavutil51 ALSO from that repo. Was this addition a real NEED or just a 'nice to have without gain'? I mean: xine-lib STAYS crippled, there is nothing we can do. Adding libavutil does not change that. A user wanting full 'fun' still needs to replace parts of the dist... 'Adding' new software now might start to replace libs as well (VLC Repo for example used to have the rule to NOT carry libs that are part of the distribution, in order to never have to replace them... ) Or am I just seeing issues where there are none and all of the packman / vlc issues will not happen? Then I'm happy to hear that this will not introduce more trouble. Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar <DimStar@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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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@opensuse.org> wrote:
On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar <DimStar@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@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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@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@opensuse.org> wrote:
On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar <DimStar@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@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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@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@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@opensuse.org> wrote:
On 15 June 2012 18:25, Dominique Leuenberger a.k.a DimStar <DimStar@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@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
_______________________________________________ Packman mailing list Packman@links2linux.de http://lists.links2linux.de/cgi-bin/mailman/listinfo/packman
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 June 2012 08:58, Dave Plater <davejplater@gmail.com> wrote:
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.
This is far from a "specific case". And AFAIK Debian packages the full libav and Fedora doesn't package libxine 1.2, what clues should I look for there? I guess the basic question is: why is this different to the libxine case? Packman doesn't make any effort to keep it in sync with openSUSE version. And it even packages a binary incompatible version. What's more, Packman already packages two binary incompatible versions of libavutil! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Cristian Morales Vega -
Dave Plater -
Dominique Leuenberger a.k.a DimStar