From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101014/001205.html | 164 ++++++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101014/001205.html (limited to 'zarb-ml/mageia-dev/20101014/001205.html') diff --git a/zarb-ml/mageia-dev/20101014/001205.html b/zarb-ml/mageia-dev/20101014/001205.html new file mode 100644 index 000000000..97187961d --- /dev/null +++ b/zarb-ml/mageia-dev/20101014/001205.html @@ -0,0 +1,164 @@ + + + + [Mageia-dev] Mageia repository sections, licenses, restrictions, firmware etc + + + + + + + + + +

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

+ Anssi Hannula + anssi.hannula at iki.fi +
+ Thu Oct 14 20:55:01 CEST 2010 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1