[Mageia-dev] Mirror layout, round two

[Michael scherer]

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