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

Fri Feb 18 13:47:44 CET 2011

On 18/02/11 12:07, Michael Scherer wrote:
+> 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 ).
+>
+
+If there are two packages, one in core and another in tainted, then 
+doesn't urpmi need a way to recognise that the tainted package is newer 
+than (an update to) the corresponding core package? I believe that this 
+is achieved in Mandriva, because plf is greater than mdv.
+
+Jim
+
+