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

[Vladimir Mosgalin]

Hi Dominik 'Rathann' Mierzejewski!

 On 2007.05.01 at 10:39:32 +0200, Dominik 'Rathann' Mierzejewski wrote next:

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

Great. It doesn't change the fact that when I experienced this bug I
found that bugzilla record is several months old. (I had to install
mplayer package because of some other 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)
> 
> 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.

Right. Maybe situation is better right now, then again: when I had
problems compiling a program that wanted either libmp4v2 or libmp4ff and
all faad2 versions around missed that library fixing all the loose ends
and getting these libraries without breaking anything was a bit painful.
It seems that freshrpms started providing libmp4v2 earlier than extras,
of course it doesn't matter anymore.

> > http://bugzilla.livna.org/show_bug.cgi?id=1246 (come on, how hard can be
> > fixing that?)
> 
> The "Packages" product category already has FC6.

Is this a joke? I was talking about "OS" field. Something had to be
entered, and there were no FC6 choice! Or something like this. It has
been changed overnight so I can't comment on this anymore!

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

Maybe, I was annoyed at it when I tried to browse livna before mirroring
it. I prefer to keep local rsync'ed copies of all repos that I use,
since I have more than one PC that uses them.

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

So what? Shipping a private header would hardly break anything. And if
it fixes some other package without breaking others, it's a packager job
to fix it. This kind of reasoning can be used against avidemux, but repo
packager shouldn't use it for giving trouble to his users, if he doesn't
want to lose them. Nobody likes such fixes, but the world isn't ideal.

As a side note, no other fedora repository has fixed this too, and
the fact that it was fixed in gentoo can hardly be a good example (I
respect gentoo as a source of up-to-date compatibility fixes and for its
excellent wiki, but find it too terrifying to use). But no other
repository provides avidemux.

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

I don't understand this legal part. The only packages that could be
distributed legally are in core/extras, and all other stuff, like mp3
support can't be legally distributed anyway? However if you either live
in country which doesn't forbid their distribution and usage (I do) or
live in USA and want to take personal consequences for their usage in
case something goes wrong, you can do it.

With this kind of policy, I fail to see how use of GPL-incompatible
modules or patented codes differ. They are both legal or semi-legal for
personal usage (all GPL restrictions cover only distribution), and they
both can be considered illegal for distribution under certain
circumstances.

In other words: even if there is some extremely illegal package in livna
or freshrpms, overall status of these repos stays the same.

Btw, amrnb package is marked as "LGPL" in rpm license tag. And
/usr/share/doc/amrnb-0.0.1/COPYING file is guess what.. GPL. I don't
know what it means, looks a bit fishy, still I don't think anything is
wrong with this package.

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

Sure it is. Still, it's usually much nicer user, when he updated kernel
and kernel modules aren't updated yet - with dkms, user won't even
notice the problem.

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

You told that it won't be fixed anyway (libdca, I don't know how to fix
avidemux)..

I never submitted the patch because of that note in changelog that
sounded like "it's almost fixed" and because I found the patch myself
with the first google query. Surely I thought that anyone who decides to
fix that knows how to use google?

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

I meant the fact that livna completely ignores existence of other
repositories. Not that you can't contribute to it if you try very hard,
but that interoperability contributions aren't welcome.

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

Would it be too hard supporting both? (on the other hand, it doesn't
look like freshrpms has problems even without support..).
Anyway, it's up to you. Like I said, I used livna in the past; I still
do on some old FC installations, because I'm to lazy to switch it off.
However, now I consider that a mistake which only leads to problems and
don't enable it on newer installs. I won't be using it on any F7 system
for sure.

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

Don't know about mplayer, it can use either system-wide 2.5 or internal
version or maybe even some kind of ffmpeg decoder - who cares, as longer
as it works. There are patches for xine-lib and gstreamer-plugins-bad
that make them compile against 2.5, but drop 2.0 compatibility. You
cannot take recent gstreamer from freshrpms, probably even SRPM and make
it work with old faad in livna (and surprise, rpm dependencies won't
help you on that, you'll just end with broken aac support in gstreamer).
Latest patched gstreamer-plugins-bad doesn't support faad 2.0, can't say
for sure about xine-lib extras package, none of the programs that I use
uses xine, but at least it requires faad 2.5..

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

Who knows.. I hope that merged repo will keep compatibility with dries,
though.

-- 

Vladimir