[packman] Packman is becoming like a leaky boat full of patches.

[Manfred Tremmel]

Am Samstag, 18. Juni 2011 schrieb Dave Plater:
> On 06/18/2011 05:06 PM, Manfred Tremmel wrote:
> > libswscale.so.0 build from ffmpeg master and ffmpeg oldabi branches
> > are no longer compatible. I don't have the time/knowledge to port
> > all our programms to be compatible with the new abi, so we need to
> > provide both abi version. To provide both libs I've created the
> > subpackages libswscale0 out of the ffmpeg master branch package
> > and
> > libswscale_oldabi0.
> > If you compile against a package which is build against
> > ffmpeg-oldabi, you should add a "BuildRequires:
> > libswscale_oldabi0" entry, otherwise use "BuildRequires:
> > libswscale0".
> 
> There's something shared between ffmpeg and mjpegtools?

AFAIK not. There are a view libs start with libav*, but they do not 
match with the ffmpeg libs. They are build out of the lavtools 
directory.

> The pkg-config file states "Cflags: -I${includedir}
> -I${includedir}/mpeg2enc -I${includedir}/mplex" but I can't seem to
> find the packages that mpeg2enc and mplex come from, maybe it's
> because I didn't have an uncrippled mjpegtools 1.9.0 handy.

No Problem: http://packman.links2linux.de/package/mjpegtools19

>   I see that there's two versions of libmp4v2 installed on my system.
> I think a cleanup of parallel installed libraries is needed in
> multimedia in general, a good start would be BuildRequire:ing the
> newest versions and having a serious look at why the old libs are
> still needed by "up to date packages?"

To have more then one libmp4v2 needn't mean they both are needed. The 
packaging police with the version in the package name (libxyz1, libxyz2, 
...) means old libs are not removed automaticly.

> Especially ffmpeg I've seen new packages requiring specific older
> ffmpeg and bundling it, (can't remember the package name) if you
> then match that to system ffmpeg you'll find out why they bundled a
> particular version. If for example something like ffmpeg or

And included ffmpeg versions mostly are horribly supported. In xine-lib 
there's e.g. the included ffmpeg version was updated nearly two years 
ago. No security fixes, no other changes. This means a xine-lib build 
with included ffmpeg version is a extreme security problem. I don't 
think other projects backport all the fixes.

> mjpegtools had unmarked abi changes which caused bugs in programs
> that used them and these bugs were "fixed" in the calling program,

I've fixed a view programms to work with the new ffmpeg abi. Every 
change I had to do, was documented in ffmpegs doc/APIchanges. Most 
things where marked as deprecated since years, but nobody seems to be 
interested in. Deprecated warnings shouldn't be ignored by the 
developers. So it's not so spectaculary the old way didn't work anymore.

> I'm talking about something that has crept in long ago and possibly
> worsened with time. Possibly even because the major distributions
> don't apply the same standards to the grey area software as they do
> to internal stuff. I've never experienced the instability of
> multimedia software in any other catagories, even with beta releases
> of kde and bleeding edge samba. Packman and Videolan need to
> synchronise ffmpeg naming to prevent parts of the vlc build getting
> mixed with the Packman build. Packages which only build with old
> libraries should be in an isolated repository with the old libraries
> and a bug filed upstream about the inability to run/build with newer
> libs.

We care about our projects, but I don't think it's possible to take care 
on every other repo which maybe uses the same packages in different 
versions.

> There are multimedia audio packages that are trouble free and
> blender-2.57b uses or will be able to use once python3-3.2 is in
> factory (or I'm allowed to put a link in Packman), but video and
> related packages that use video libs are generally not so stable.
> 
> I'm busy replying to you in two emails, the other one relates
> specifically to mjpegtools which doesn't follow traditional library
> naming conventions. If I can find problems, there's a lot of people
> I can ask how to fix it but I have to be specific.

Better solutions are wellcome.

-- 
Machs gut    | http://www.iivs.de/schwinde/buerger/tremmel/

Manfred      | http://packman.links2linux.de/