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

[Dominik 'Rathann' Mierzejewski]

Hi,

On Tuesday, 01 May 2007 at 13:15, Vladimir Mosgalin wrote:
> Hi Dominik 'Rathann' Mierzejewski!
> 
>  On 2007.05.01 at 10:39:32 +0200, Dominik 'Rathann' Mierzejewski wrote next:
> 
[...]
> > > 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.

So was I. Sorry if I wasn't explicit, but I've been filing bugs against FC6
release of livna a couple of months ago.

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

It hasn't been changed overnight. It's just that the bugreport hasn't been
closed when it should.

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

I usually don't introduce dirty hacks just to make something work and I
suspect other livna packagers feel that way, too.

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

Legally in the US.

> and all other stuff, like mp3 support can't be legally distributed anyway?

Not in the US, but it can be distributed in most of Europe.

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

They differ. In livna, we don't care about patents, because we're located
in a country where software cannot be patented. Whereas when the software
license itself prohibits redistribution, it's a different matter altogether.

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

The library glue code is under an open source license, but it still
requires the underlying AMR reference code to be compiled and linked with
it. Hence they cannot be distributed together.

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

No. I said it won't be fixed in the wrong way. If you have a proper fix,
please send it.

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

That's not a fix. That's a bad hack.

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

Sure they are welcome, as long as they don't break anything.

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

Double work for me.

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

Dries' is one of the repos doing the merge.

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