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

[James Kerr]

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