[MPlayer-dev-eng] [OT] livna vs. freshrpms (was: Re: 64-bit issue in ad_faad.c)

Tue May 1 10:39:32 CEST 2007

Forgive me this offtopic mail, but I need to set those issues straight.

On Monday, 30 April 2007 at 23:29, Vladimir Mosgalin wrote:
> 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".

Not exactly. It's more of "becoming incompatible with other repos shouldn't
stop me from packaging software the way I think is best," but yes, it is so.

> > 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.

Help is welcome.

> 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
> on it)

It's been fixed for some months now. I've just closed it.

> 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)

libmp4v2 has moved to Fedora and besides, software which uses an non-public
APIs from an external library (libmp4ff) is broken and should either be
fixed or shipped with its own copy of the headers.

> http://bugzilla.livna.org/show_bug.cgi?id=1246 (come on, how hard can be
> fixing that?)

The "Packages" product category already has FC6.

> http://bugzilla.livna.org/show_bug.cgi?id=1262 (ditto)

Not really a bug. The mirrorlist file is not used in yum configs.
mirrorlist-6 is used and that's already working.

> http://bugzilla.livna.org/show_bug.cgi?id=1414

We have a new maintainer of mldonkey. Once his new package passes
review, there'll be a new version.

> 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).

That's because - again - the header in question contains non-public APIs,
so "fixing" this with shipping the private header is obviously wrong.

[...]
> 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.

MAC code is GPL-incompatible and has been removed from SourceForge because
the maintainer lied to them about it (he even says so in COPYING). So while
it can be distributed, I'm not sure of what use it is.

AMR reference code is not distributable without explicit permission. If
freshrpms chooses to do something illegal, well, I won't stop them.

libmp4v2 is, as I mentioned earlier, already in official Fedora repo.

> 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..).

You're exaggerating.

dkms has its drawbacks, as does any other way of packaging out-of kernel
modules. That's why they should all be in-kernel. We chose to follow
Fedora's way of packaging, for better and for worse.

> 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?

Well, we're working towards a single third-party repo. We want to merge
freshrpms, livna, atrpms and whoever else wants to join. We welcome
any and all the help we can get: http://www.rpmfusion.net/ .

> The only "livna-only" package that I use, avidemux, has problems, so I
> build it myself anyway..

Patches are welcome. ;) Seriously, if you can offer any help, we'll gladly
take it.

> My opinion is that livna suffered from closeness of its development
> process

The process is open. See here for details:
http://rpm.livna.org/rlowiki/Contributors

> 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 was the only packager who stepped up and asked for it and worked
with MPlayer developers to achieve it. I decided to join livna later.
Are you telling me to leave them and join freshrpms instead?

> > > 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.

MPlayer isn't. Xine isn't either.

So there you have it. Your only argument that's still standing is that we're
in some cases incompatible with other repos. Believe me that there's a good
reason for most of those incompatiblities. Well, after the merge happens,
this will be moot anyway.

Regards,
R.

-- 
MPlayer developer and RPMs maintainer: http://mplayerhq.hu http://rpm.livna.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan