summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20101127/001442.html
blob: 877045a4d5b89da37f85eff89eebfccfba38f5f2 (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
151
152
153
154
155
156
157
158
159
160
161
<!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=%3C4CF041DD.7010804%40iki.fi%3E">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="001440.html">
   <LINK REL="Next"  HREF="001443.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] Mirror layout, round two</H1>
    <B>Thomas Backlund</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Mirror%20layout%2C%20round%20two&In-Reply-To=%3C4CF041DD.7010804%40iki.fi%3E"
       TITLE="[Mageia-dev] Mirror layout, round two">tmb at iki.fi
       </A><BR>
    <I>Sat Nov 27 00:25:17 CET 2010</I>
    <P><UL>
        <LI>Previous message: <A HREF="001440.html">[Mageia-dev] Mirror layout, round two
</A></li>
        <LI>Next message: <A HREF="001443.html">[Mageia-dev] Mirror layout, round two
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#1442">[ date ]</a>
              <a href="thread.html#1442">[ thread ]</a>
              <a href="subject.html#1442">[ subject ]</a>
              <a href="author.html#1442">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Maarten Vanraes skrev 27.11.2010 01:02:
&gt;<i> Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL:
</I>&gt;&gt;<i> On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote :
</I>&gt;&gt;&gt;<i> Then we come to the &quot;problematic&quot; part:
</I>&gt;&gt;&gt;<i> ------
</I>&gt;&gt;&gt;<i> x86_64
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i>          media
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i>                codecs (disabled by default)
</I>&gt;&gt;&gt;<i>                core (old main+contrib)
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i>                     backports (disabled by default)
</I>&gt;&gt;&gt;<i>                     backports_testing (disabled by default)
</I>&gt;&gt;&gt;<i>                     release
</I>&gt;&gt;&gt;<i>                     testing (disabled by default)
</I>&gt;&gt;&gt;<i>                     updates
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i>                extra (unmaintained, disabled by default)
</I>&gt;&gt;&gt;<i>                firmware (disabled by default)
</I>&gt;&gt;&gt;<i>                games (disabled by default)
</I>&gt;&gt;&gt;<i>                non-free (disabled by default)
</I>&gt;&gt;&gt;<i>                /debug_*/ (disabled by default)
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i> -----
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i> The idea of this layout with some of the separate sections (codecs,
</I>&gt;&gt;&gt;<i> firmware, games, non-free, debug_*) gives a mirror maintainer in a
</I>&gt;&gt;&gt;<i> country (or company) the option to exclude the parts they legally (or by
</I>&gt;&gt;&gt;<i> company policy) can not mirror.
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i> The &quot;core&quot; should be only maintained free/libre stuff so it's easy to
</I>&gt;&gt;&gt;<i> build a free/libre iso
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i> &quot;extra&quot; is for those packages that no-one really maintain, but is still
</I>&gt;&gt;&gt;<i> used by someone
</I>&gt;&gt;&gt;<i>
</I>&gt;&gt;&gt;<i> &quot;games&quot; are now a separate repo since it can grow fast with a lot of
</I>&gt;&gt;&gt;<i> game data.
</I>&gt;&gt;<i>
</I>
[...]

&gt;<i> A) i see no reason for codecs and firmware to be separate. However, i do
</I>&gt;<i> understand that some people would not want to install firmware, but i think we
</I>&gt;<i> should do this in another way, (like installing a meta package that enforces
</I>&gt;<i> some limits.)
</I>&gt;<i> codecs seem odd to be separate, if they have patented problems they should go
</I>&gt;<i> in non_free, if no problem, they can go in core.
</I>&gt;<i>
</I>
That is doable.
The reason for having it separate was because its the most &quot;problematic&quot; 
one. (codecs have more issues than firmware)

&gt;<i> B) if they are separate, they would need updates, backports, testing, ... (i
</I>&gt;<i> expect non_free does too?)
</I>&gt;<i>
</I>
Yep.
as noted in the other post, the layout under /core/ is duplicated under 
all other medias...

&gt;<i> C) if they are separate, they cannot be disabled by default, some stuff is
</I>&gt;<i> needed for stuff to work.
</I>&gt;<i>
</I>
So installer could ask &quot;in order to fully support your hw you need ..., 
do you want to enable firmware repo...&quot; and explain the reason for 
free/libre...

&gt;<i> D) i have questions about noarch packages, will they be installed on both
</I>&gt;<i> trees? and if we have more archs later on, more and more? this seems a waste;
</I>&gt;<i> except if we could hardlink them somehow. if not, we should just put them
</I>&gt;<i> somewhere separate.
</I>&gt;<i>
</I>
We hardlink them already.
But yeah, I'd like a separate noarch too, but some people disagree, so I 
didnt add it to this proposal.

&gt;<i> E) i understand games to be separate, but disabled by default?, i'm not sure i
</I>&gt;<i> agree with that. (we need to remember our target audience; stuff needs to work
</I>&gt;<i> out-of the box)
</I>
I was thinking of a feature in the installer, if you select games, it 
would enable the repo by default, otherwise keep it disabled.

&gt;<i> F) what is backports_testing? why can't that just be testing?
</I>
Versioning problem... on mirrors / BS
we have testing -&gt; updates route,
so this would be backports_testing -&gt; backports,

Because if you have this:
core/release v 1.2.0-1
core/testing v 1.3.0-1 (intended for backports)

then you cant upload a bugfix v 1.2.0-1.1 to core/testing as there is 
already a bigger version in testing...

--
Thomas


</PRE>


<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="001440.html">[Mageia-dev] Mirror layout, round two
</A></li>
	<LI>Next message: <A HREF="001443.html">[Mageia-dev] Mirror layout, round two
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#1442">[ date ]</a>
              <a href="thread.html#1442">[ thread ]</a>
              <a href="subject.html#1442">[ subject ]</a>
              <a href="author.html#1442">[ 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>