Le vendredi 18 février 2011 à 12:43 +0100, Oliver Burger a écrit : > Philippe DIDIER <philippedid...@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