[Mageia-dev] About panotools patent problem (and other problematic rpms)

[Michael Scherer]

Le vendredi 18 février 2011 à 12:43 +0100, Oliver Burger a écrit :
> Philippe DIDIER <philippedidier at laposte.net> schrieb am 2011-02-18
> > And what I talked about (in the other thread with the same name)
> > was about the easiness to build and use different rpms with the
> > same spec having mdv versus plf suffixes...
> > And about it seems that we need to have different naming for Mageia
> > (whether it's a "normal" or tainted rpm)
> I still don't see a reason for this. We devide those packages by the 
> repo they get in, why do another thing?

>From a build system point f view, this is easier to indeed treat that
like non-free, because there is no modification to do.

A better solution would indeed be to allow to have a tainted rpm in code
and tained, the core version being "cleaned" from litigious parts.

let's take a exemple, let's imagine someone has a patent on a fictional
video codec let's call it MCVC ( MegaCompressionVideoCodec ), and a army
of cloned lawyers from Hell that enforce the patent in USA. 

Let's assume that Mplayer, as it support almost everything, support MCVC
in the current version. 

First solution : we move mplayer rpm to tainted, with support for MCVC.

Second solution : we compile mplayer in core without support for MCVC

Third solution : we compile mplayer 2 times, once in tainted with MCVC,
another one to core without.


The first solution force us to place everything that requires mplayer to
tainted, as core must be self contained. So that mean various frontends,
firefox plugin, etc. This could be problematic if we place some
libraries in tainted. ( like freetype ).

The second solution may slightly annoy people with lots of holidays
movies encoded in MCVC. And would render tainted basically useless.

The third solution is the one we use for PLF, but suffer from a few
technical issues :
- I am not sure the current system support it. In mdv, the 2 uploads
system are fully separated. Not here.

- We need to make sure that the binaries and source rpms are kept in
sync. If I upload a new version of mplayer, it will erase the source rpm
and use the new one. So if I built the tainted one, the srpm that was
used for the core rpm is no longer here.
 
- we need to make sure that the binaries rpms are in sync. If we upload
the core one, it would be nice to wait for the tainted one to be
uploaded too. Ie keep them in sync like we keep x86_64/i586 in sync.
But, only if the package is dual lived ( ie, there is rpms that will be
distributed only in tainted ).

That's a rather non trivial problem to solve.

And hopefully, we only have core and tainted ( ie, while non-free could
be added to the mix, there is no dual life issue with it ).

-- 
Michael Scherer