summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20101127/001440.html
blob: 6ddb4f113b9947baaeb5ba17de08d1a47d3973b3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
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>