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