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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
|
<!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=%3C201011271401.06087.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="001451.html">
<LINK REL="Next" HREF="001459.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=%3C201011271401.06087.maarten.vanraes%40gmail.com%3E"
TITLE="[Mageia-dev] Mirror layout, round two">maarten.vanraes at gmail.com
</A><BR>
<I>Sat Nov 27 14:01:06 CET 2010</I>
<P><UL>
<LI>Previous message: <A HREF="001451.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001459.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1458">[ date ]</a>
<a href="thread.html#1458">[ thread ]</a>
<a href="subject.html#1458">[ subject ]</a>
<a href="author.html#1458">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Op zaterdag 27 november 2010 09:43:54 schreef Michael scherer:
><i> On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote:
</I>><i> > Hi,
</I>><i> > As we are getting closer to actually have something to mirror it's
</I>><i> > time to get this decided.
</I>><i> >
</I>><i> > And the deadline for theese discussions is December 5th, 2010 in
</I>><i> > order to get a decision on the board meeting on December 6th, 2010.
</I>><i> >
</I>><i> >
</I>><i> > Now this is a somewhat problematic topic but needs to be decided.
</I>><i> > This has already been discussed in two threads:
</I>><i> >
</I>><i> > First off we have the "basic) part:
</I>><i> > "Mirror tree structure" by Olivier Thauvin
</I>><i> > <A HREF="https://www.mageia.org/pipermail/mageia-dev/20101020/001286.html">https://www.mageia.org/pipermail/mageia-dev/20101020/001286.html</A>
</I>><i> >
</I>><i> > And the other part (that gives some problems):
</I>><i> > "Mageia repository sections, licenses, restrictions, firmware etc"
</I>><i> > by Anssi Hannula.
</I>><i> > <A HREF="https://www.mageia.org/pipermail/mageia-dev/20101012/001084.html">https://www.mageia.org/pipermail/mageia-dev/20101012/001084.html</A>
</I>><i> >
</I>><i> >
</I>><i> > Now, in order to get somewhere, here is a suggestion that tries to
</I>><i> > find a middle ground or base for discussions...
</I>><i> >
</I>><i> > Now this toplevel part seems to be ok by everyone:
</I>><i> > ------
</I>><i> > Mageia/
</I>><i> >
</I>><i> > /distrib/
</I>><i> >
</I>><i> > /cauldron/
</I>><i> > /stable1/
</I>><i> >
</I>><i> > /iso/
</I>><i> >
</I>><i> > /cauldron/
</I>><i> >
</I>><i> > /i586/
</I>><i> > /srpms/
</I>><i> > /x86_64/
</I>><i> >
</I>><i> > /stable1/
</I>><i> >
</I>><i> > /people/
</I>><i> > /software/
</I>><i> >
</I>><i> > ------
</I>><i>
</I>><i> > Then we come to the "problematic" part:
</I>><i> This part look really too complex to me.
</I>><i>
</I>><i> > ------
</I>><i> > /x86_64/
</I>><i> >
</I>><i> > /media/
</I>><i> >
</I>><i> > /codecs/ (disabled by default)
</I>><i>
</I>><i> so, ogg, webm, being codec, should go there or not ?
</I>><i> What about patents problem about something else than codec ?
</I>><i> ( freetype, image such as gif, DRM stuff )
</I>><i>
</I>><i> > /core/ (old main+contrib)
</I>><i> >
</I>><i> > /backports/ (disabled by default)
</I>><i> > /backports_testing/ (disabled by default)
</I>><i> > /release/
</I>><i> > /testing/ (disabled by default)
</I>><i> > /updates/
</I>><i> >
</I>><i> > /extra/ (unmaintained, disabled by default)
</I>><i>
</I>><i> If used by people, then why no one step to maintain anything ?
</I>><i> If someone take the maintainace, does it mean that we will move the package
</I>><i> ?
</I>><i>
</I>><i> > /firmware/ (disabled by default)
</I>><i>
</I>><i> Why separate firmware from non_free ? What does it bring ?
</I>><i> Since both of them are disabled by default, they can be simply merged.
</I>><i>
</I>><i> > /games/ (disabled by default)
</I>><i>
</I>><i> That's a simplification that make no sense.
</I>><i> Not all games are big, not all big packages are games ( tetex, openoffice
</I>><i> ).
</I>><i>
</I>><i> This only bring complexity on our side, complexity on mirror side, and
</I>><i> bring few improvement to users. A rather more precise label would be to
</I>><i> have /contents/ repository, as this is not the game that take space, but
</I>><i> the content.
</I>
for this one, i don't really agree. I think it's purpose would be to have a
repository that not all mirrors have to mirror (it's optional; and it'll
probably be very big). call it whatever you will, it'll mostly contain big
games. (imo, it could be like this: if this package would not be essential and
more than X MB (200?; 250?) it could be in this repository, no matter if it's
free or non_free; mirror maintainers can largely assume those to be non_free
for mirrorring purposes) or even split those up.
this is because some mirrors will not be able to mirror core when the big
games are in core/non_free.
><i> And a explicit policy of splitting content from big packages, with a
</I>><i> explicit size or expected size for limit ( like if the package is more
</I>><i> than 100 mo ). That's also a media where deltarpm would make sense, or
</I>><i> someting like that. In the mean time this would only bring complexity to
</I>><i> everybody else.
</I>><i>
</I>><i> > /non-free/ (disabled by default)
</I>><i> > /debug_*/ (disabled by default)
</I>><i>
</I>><i> And what are the relation of requirements ?
</I>><i> Ie, what can requires non_free, codecs, games, etc ?
</I>><i>
</I>><i> And what about something that can goes in both media, ie a non_free
</I>><i> game goes where ? A unmaintained codecs goes where ?
</I>
relations between them are important:
mirrors should:
- always have core
- the rest is optional; but there should be a text file somewhere which tells
us what repositories are in here.
- (bear in mind that i consider firmware and codecs non-existing)
what also needs to happen is to have mirrorlist working better:
if a mirror doesn't have some repositories, it should fetch the next one.
also, some kind of timings could be interesting; a way of determining how long
ago this mirror has been synced with primary mirror; ie: a way of determining
a temporary stale mirror ==> next mirror in the list.
MD5SUM files should be forcably requested to not have a cached version; when i
was working on urpmi-proxy, i noticed that there is a way to find out if a
certain file has been modified.
I'm willing to spend some time on urpmi for this stuff to work well.
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="001451.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001459.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1458">[ date ]</a>
<a href="thread.html#1458">[ thread ]</a>
<a href="subject.html#1458">[ subject ]</a>
<a href="author.html#1458">[ 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>
|
