diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20101127/001458.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20101127/001458.html | 197 |
1 files changed, 197 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20101127/001458.html b/zarb-ml/mageia-dev/20101127/001458.html new file mode 100644 index 000000000..b7daaf2f5 --- /dev/null +++ b/zarb-ml/mageia-dev/20101127/001458.html @@ -0,0 +1,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> |