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

Fri Feb 18 13:07:52 CET 2011

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