[Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc

[Anssi Hannula]

On Wednesday 13 October 2010 20:22:01 Michael Scherer wrote:
> Le mardi 12 octobre 2010 à 18:02 +0300, Anssi Hannula a écrit :
> > Hi all!
> > 
> > Do people have any thoughts on what kind of repository/media sectioning
> > we should use on Mageia, and what should those sections contain?
> > 
> > Note that I won't talk about backports / private repositories in this
> > post, only about the basic sectioning and packages in those.
> > 
> > Some points to consider (I've written my opinion in ones where I have
> > one):
> > 
> > == Do we want a separated core repository?
> > 
> > No separated core: Fedora, Debian, Opensuse
> > Separated core: Mandriva (main), Ubuntu (main), Arch (Core)
> 
> How do we decide what would be in core ?

AFAICS the only reasonable reason would be to separate 'supported' and 
'unsupported' packages (whatever the definition we will choose for those).

However, as-is the Mandriva system creates problems like the java one, where a 
builddependency mess causes everything to be in Main. It would probably be 
enough if run-time deps only were considered...

Also there are things like the kde upstream networkmanager stuff, where one 
component of a bigger source rpm (kdefoo4) depends on an 'unsupported' package 
(networkmanager). It could be allowed to put only one subpackage into Contrib.


On the other hand, we could simply use some tags (or Provides, or some other 
method) to denote the support status. This would fix the above to issues with 
the previous system. Of course, to do that, there needs to be support in 
rpmdrake/urpmi to properly handle such tag (and allow the user to disable 
'unsupported' packages if wanted).

> > == What about patents?
> > 
> > Almost no software with patents: Fedora, Opensuse
> > 
> >  - Essentially no media codecs except theora/vorbis/ogg/vp8 etc.
> >  - Strange exception: libXft, Cairo and Qt4 are shipped with LCD
> >  filtering
> >  
> >    support enabled, even if it is disabled in freetype
> > 
> > No software with enforced patents: Debian
> > 
> >  - not included (at least): x264 (encoder), lame mp3 (encoder)
> >  - included (at least): MPEG/x decoders, H.264 decoders, MP3 decoders,
> >  
> >    AAC decoders, AMR decoders, DTS decoders, AC3 decoders,
> >    WMV/WMA decoders, realvideo decoders, etc
> > 
> > Some software covered by patents not included: Mandriva
> > 
> >  - see below for more information
> > 
> > All software covered by patents allowed: Arch, Ubuntu
> > 
> > 
> > IMO we should alter our policy to match either Fedora, Debian or
> > Ubuntu.. The Mandriva policy makes no sense (for example, no AAC
> > decoder but yes for H.264 decoder and MPEG-4 encoder?).
> > I'm really not sure which way we should go, though. WDYT?
> 
> I would go the Debian way.
> Ubuntu and Fedora are tied to companies, and Debian is not, so their
> policies are likely more adapted to our own model.
> 
> Debian way seems to be more pragmatic that Ubuntu/Fedora on that matter.

Indeed, Debian's situation seems closer to ours.

However, a bit more investigation shows that the Debian policy "no enforced 
patents" is not really a written policy and what it means in practice is not 
100% clear. A clarification request [1] has gone unanswered for 1.5 years, and 
"missing" packages x264,lame,xvidcore are sitting in the NEW queue [2] without 
having been accepted or rejected yet (it has "only" been 2.5 months, though).


BTW, other related 'missing' packages in debian are "mjpegtools", "faac", 
"transcode", but the first two are missing due to license reasons instead of 
patent issues:

mjpegtools contains source files that are "All Rights Reserved" by "MPEG/audio 
software simulation group" (Ubuntu has the package in multiverse, Mandriva in 
main)

faac contains a limitation that it is not allowed to be used in software not 
conforming to MPEG-2/MPEG-4 Audio standards, which makes it non-opensource 
(Ubuntu has the package in multiverse, Mandriva doesn't have it).

transcode is missing, but there's been no recent activity on it that would 
explain why it isn't there (IIRC its supported codecs are a subset of ffmpeg 
ones, and ffmpeg is in Debian).


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522373
(note that debian had some encoders disabled in ffmpeg at the time of the 
above report; those have since been enabled)
[2] http://ftp-master.debian.org/new.html

-- 
Anssi Hannula