[Mageia-dev] Mirror layout, round two

Sat Nov 27 09:43:54 CET 2010

On Fri, Nov 26, 2010 at 10:29:14PM +0200, Thomas Backlund wrote:
+> Hi,
+> As we are getting closer to actually have something to mirror it's
+> time to get this decided.
+> 
+> And the deadline for theese discussions is December 5th, 2010 in
+> order to get a decision on the board meeting on December 6th, 2010.
+> 
+> 
+> Now this is a somewhat problematic topic but needs to be decided.
+> This has already been discussed in two threads:
+> 
+> First off we have the "basic) part:
+> "Mirror tree structure" by Olivier Thauvin
+> https://www.mageia.org/pipermail/mageia-dev/20101020/001286.html
+> 
+> And the other part (that gives some problems):
+> "Mageia repository sections, licenses, restrictions, firmware etc"
+> by Anssi Hannula.
+> https://www.mageia.org/pipermail/mageia-dev/20101012/001084.html
+> 
+> 
+> Now, in order to get somewhere, here is a suggestion that tries to
+> find a middle ground or base for discussions...
+> 
+> Now this toplevel part seems to be ok by everyone:
+> ------
+> Mageia/
+>       /distrib/
+>               /cauldron/
+>               /stable1/
+>       /iso/
+>           /cauldron/
+>                   /i586/
+>                   /srpms/
+>                   /x86_64/
+>           /stable1/
+>       /people/
+>       /software/
+> ------
+> 
+> 
+> Then we come to the "problematic" part:
+
+This part look really too complex to me. 
+
+> ------
+> /x86_64/
+>        /media/
+>              /codecs/ (disabled by default)
+
+so, ogg, webm, being codec, should go there or not ?
+What about patents problem about something else than codec ?
+( freetype, image such as gif, DRM stuff )
+
+>              /core/ (old main+contrib)
+>                   /backports/ (disabled by default)
+>                   /backports_testing/ (disabled by default)
+>                   /release/
+>                   /testing/ (disabled by default)
+>                   /updates/
+>              /extra/ (unmaintained, disabled by default)
+
+If used by people, then why no one step to maintain anything ?
+If someone take the maintainace, does it mean that we will move the package ?
+
+>              /firmware/ (disabled by default)
+
+Why separate firmware from non_free ? What does it bring ?
+Since both of them are disabled by default, they can be simply merged.
+
+>              /games/ (disabled by default)
+
+That's a simplification that make no sense. 
+Not all games are big, not all big packages are games ( tetex, openoffice ). 
+
+This only bring complexity on our side, complexity on mirror side, and
+bring few improvement to users. A rather more precise label would be to have 
+/contents/ repository, as this is not the game that take space, but the content.
+
+And a explicit policy of splitting content from big packages, with a explicit size or
+expected size for limit ( like if the package is more than 100 mo ). That's also a media
+where deltarpm would make sense, or someting like that. In the mean time this would
+only bring complexity to everybody else.
+
+>              /non-free/ (disabled by default)
+>              /debug_*/ (disabled by default)
+
+
+And what are the relation of requirements ?
+Ie, what can requires non_free, codecs, games, etc ? 
+
+And what about something that can goes in both media, ie a non_free 
+game goes where ? A unmaintained codecs goes where ?
+-- 
+Michael Scherer
+