summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20101127/001440.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/20101127/001440.html')
-rw-r--r--zarb-ml/mageia-dev/20101127/001440.html150
1 files changed, 150 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101127/001440.html b/zarb-ml/mageia-dev/20101127/001440.html
new file mode 100644
index 000000000..6ddb4f113
--- /dev/null
+++ b/zarb-ml/mageia-dev/20101127/001440.html
@@ -0,0 +1,150 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Mageia-dev] Mirror layout, round two
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011270002.54638.maarten.vanraes%40gmail.com%3E">
+ <META NAME="robots" CONTENT="index,nofollow">
+ <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
+ <LINK REL="Previous" HREF="001439.html">
+ <LINK REL="Next" HREF="001442.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Mageia-dev] Mirror layout, round two</H1>
+ <B>Maarten Vanraes</B>
+ <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C201011270002.54638.maarten.vanraes%40gmail.com%3E"
+ TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com
+ </A><BR>
+ <I>Sat Nov 27 00:02:54 CET 2010</I>
+ <P><UL>
+ <LI>Previous message: <A HREF="001439.html">[Mageia-dev] Mirror layout, round two
+</A></li>
+ <LI>Next message: <A HREF="001442.html">[Mageia-dev] Mirror layout, round two
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1440">[ date ]</a>
+ <a href="thread.html#1440">[ thread ]</a>
+ <a href="subject.html#1440">[ subject ]</a>
+ <a href="author.html#1440">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL:
+&gt;<i> On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote :
+</I>&gt;<i> &gt; Then we come to the &quot;problematic&quot; part:
+</I>&gt;<i> &gt; ------
+</I>&gt;<i> &gt; x86_64
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; media
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; codecs (disabled by default)
+</I>&gt;<i> &gt; core (old main+contrib)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; backports (disabled by default)
+</I>&gt;<i> &gt; backports_testing (disabled by default)
+</I>&gt;<i> &gt; release
+</I>&gt;<i> &gt; testing (disabled by default)
+</I>&gt;<i> &gt; updates
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; extra (unmaintained, disabled by default)
+</I>&gt;<i> &gt; firmware (disabled by default)
+</I>&gt;<i> &gt; games (disabled by default)
+</I>&gt;<i> &gt; non-free (disabled by default)
+</I>&gt;<i> &gt; /debug_*/ (disabled by default)
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; -----
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; The idea of this layout with some of the separate sections (codecs,
+</I>&gt;<i> &gt; firmware, games, non-free, debug_*) gives a mirror maintainer in a
+</I>&gt;<i> &gt; country (or company) the option to exclude the parts they legally (or by
+</I>&gt;<i> &gt; company policy) can not mirror.
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; The &quot;core&quot; should be only maintained free/libre stuff so it's easy to
+</I>&gt;<i> &gt; build a free/libre iso
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; &quot;extra&quot; is for those packages that no-one really maintain, but is still
+</I>&gt;<i> &gt; used by someone
+</I>&gt;<i> &gt;
+</I>&gt;<i> &gt; &quot;games&quot; are now a separate repo since it can grow fast with a lot of
+</I>&gt;<i> &gt; game data.
+</I>&gt;<i>
+</I>&gt;<i> I think it is a good layout, but, are updates/backports(testing) limited to
+</I>&gt;<i> core?
+</I>&gt;<i>
+</I>&gt;<i> As you mentioned, extra has no reason to have updates or backports, because
+</I>&gt;<i> if someone did bother to make updates, then the package doesn't belong in
+</I>&gt;<i> extra.
+</I>&gt;<i>
+</I>&gt;<i> For games it would surely be appreciated to have new versions, so maybe a
+</I>&gt;<i> only a games/updates media which could also be used as a backport media (as
+</I>&gt;<i> games are not critical).
+</I>&gt;<i>
+</I>&gt;<i> For non-free we would probably want also updates and backports, like in
+</I>&gt;<i> current mandriva.
+</I>&gt;<i>
+</I>&gt;<i> Now for firmware and codecs I don't know, are there updates for firmwares?
+</I>&gt;<i> Maybe they should be in sync with kernel updates (or external modules)?
+</I>&gt;<i> As for codecs, will it contain anything that could be covered by patents,
+</I>&gt;<i> like PLF for mandriva?
+</I>&gt;<i> Does that mean we will still have a stripped down mplayer/xine in core and
+</I>&gt;<i> a full version in codecs?
+</I>&gt;<i> But if it is only disabled and you only need to activate it in the control
+</I>&gt;<i> center to have full featured multimedia programs, it is no big deal, and if
+</I>&gt;<i> it makes life easier for people whose countries have restrictive law then
+</I>&gt;<i> we should go for it.
+</I>&gt;<i>
+</I>&gt;<i> We should probably have a clear rule to decide what cannot go in core and
+</I>&gt;<i> should in non-free (that on is pretty clear already) codecs or firmware.
+</I>&gt;<i>
+</I>&gt;<i> I hope we will soon get to the point where we will actually put packages in
+</I>&gt;<i> those repositories :-)
+</I>
+A) i see no reason for codecs and firmware to be separate. However, i do
+understand that some people would not want to install firmware, but i think we
+should do this in another way, (like installing a meta package that enforces
+some limits.)
+codecs seem odd to be separate, if they have patented problems they should go
+in non_free, if no problem, they can go in core.
+
+B) if they are separate, they would need updates, backports, testing, ... (i
+expect non_free does too?)
+
+C) if they are separate, they cannot be disabled by default, some stuff is
+needed for stuff to work.
+
+D) i have questions about noarch packages, will they be installed on both
+trees? and if we have more archs later on, more and more? this seems a waste;
+except if we could hardlink them somehow. if not, we should just put them
+somewhere separate.
+
+E) i understand games to be separate, but disabled by default?, i'm not sure i
+agree with that. (we need to remember our target audience; stuff needs to work
+out-of the box)
+
+F) what is backports_testing? why can't that just be testing?
+</PRE>
+
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI>Previous message: <A HREF="001439.html">[Mageia-dev] Mirror layout, round two
+</A></li>
+ <LI>Next message: <A HREF="001442.html">[Mageia-dev] Mirror layout, round two
+</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#1440">[ date ]</a>
+ <a href="thread.html#1440">[ thread ]</a>
+ <a href="subject.html#1440">[ subject ]</a>
+ <a href="author.html#1440">[ author ]</a>
+ </LI>
+ </UL>
+
+<hr>
+<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
+mailing list</a><br>
+</body></html>