[MPlayer-dev-eng] 64-bit issue in ad_faad.c
mosgalin at VM10124.spb.edu
Mon Apr 30 23:29:45 CEST 2007
Hi Dominik 'Rathann' Mierzejewski!
On 2007.04.30 at 18:40:05 +0200, Dominik 'Rathann' Mierzejewski wrote next:
I don't really want to flame in mplayer developer's list, but I don't
like when my opinion is considered a FUD, so..
> Yes, there are some known incompatibilities between the various repos,
> but that's only because the package sets overlap. As for "known problems",
Sure. However, some other repos manage to fix incompatibilities with
each other; but livna has a strict policy "if you have a conflict of
livna with another repository, we don't care".
> how come I haven't seen any reports from you in bugzilla.livna.org?
Very simple! I know how to use search, and the issues are annoying
enough for people to post them for me before me. I wanted to report a
problem a few times, but always found existing bug.. laying for
months.. unanswered. It's not like I had anything to add to them, they
were all very clear, but they were all ignored.
I'm talking at least about
http://bugzilla.livna.org/show_bug.cgi?id=1210 (the problem, of course,
isn't with fact of package presence, but with livna's mplayer dependency
http://bugzilla.livna.org/show_bug.cgi?id=1040 (not that I care right
now, but I had to make a custom faad version when I wanted to build a
program which required this lib)
http://bugzilla.livna.org/show_bug.cgi?id=1246 (come on, how hard can be
In one case, no bug was present. Newer version of avidemux failed to
build with libdca because of added dependency on one of the headers not
included into libdca package. I solved it by repackaging libdca (a
simple patch to libdca was floating around the net, and it was already
fixed in recent ebuild), and while I wanted to report it to livna, a new
build of avidemux came out, with line
- make a note regarding the libdca-devel problem
in changelog. There is still no bug in bugzilla, but Mr. Leemhuis
obviously knows about the problem after writing this comment, and if he
doesn't feel like submitting a bug after all, maybe it's not needed (for
the record, right now, 4 months ago, it's still not fixed).
> Either support your claim with facts or stop spreading FUD. Livna's
OK, you may think that these bugs are small and insignificant, but here
is real problem with livna: core + extras + livna usually isn't enough.
So most people /have/ to use other repos (at least the ones who care
about multimedia stuff). And with livna, this is a step into a very
I find about 20 packages from freshrpms useful, they don't present in
livna. So I either can solve conflicts by hand (i.e. multiple "exclude"
directives in yum repo configs) or.. well.. drop livna (I don't want to
think about other solutions when some repository offers more than dozen
of useful packages). Among them are some multimedia packages, like mac,
libmp4v2 and amrnb. Some packages are build differently - for example,
gstreamer with amrnb support. I don't want gstreamer-plugins-ugly from
livna to remove this support just because it has newer version.
On the path of co-existing repositories with manual excludes, more
problems await when one of the repos updates some base library.
Sometimes it's a real hell. Sometimes it's still worth to solve it by
hand, but not in this case. Because freshrpms/dries beat livna hands
down! Honestly, I don't know a single reason to use livna right now.
Even video drivers are packaged better in freshrpms (with dkms instead
of separate binary package to each kernel revision - and curse will fall
upon you if you try to use kernel from updates-testing..).
I respect livna for being most popular source of multimedia packages,
and I found it useful in the past, however now I suggest everybody to
use freshrpms instead. Livna provides no advantages over freshrpms but
gives you trouble when you want more multimedia or some package
than livna hasn't. Isn't that enough reason to stop using it?
The only "livna-only" package that I use, avidemux, has problems, so I
build it myself anyway..
My opinion is that livna suffered from closeness of its development
process and lack of interoperability with other repos. Sure, it has been
easier this way, but well.. here is result. I don't want to use it
anymore, and I know people who stopped using it for this reason.
> MPlayer RPM is the _only_ official RPM package, mind you.
I feel sad about that decision. I think that now it may be time to
rethink it. I hope that users of freshrpms don't have problems with
mplayer. I build my mplayer myself, so I don't really care anyway.
> > In this case, current faad2 version in freshrpms is 2.5.
> Which is the version with GPL incompatible license. I'm not sure it's even
> legal to distribute mplayer linked against that faad2 version.
Please spare me of legal issues. All I know is that headers from 2.5
aren't compatible with 2.0 and software is migrating to supporting 2.5.
More information about the MPlayer-dev-eng