[Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Renaud MICHEL skrev 28.11.2010 22:54:
> On dimanche 28 novembre 2010 at 21:12, Thomas Backlund wrote :
>> So the mirror medias accordingly to all comments so far would be a
>> simple:
>>
>> * core
>>     - enabled by default
>>     - mirrors must mirror this media to be listed as a mirror
>>     - only GPL stuff
>
> I guess you meant free (as defined by FSF, or we can make our own
> definition, like debian), we surely don't want to restrict ourself to GPL-
> only stuff.

Yeah. I meant to change that.
I do mean free/libre as in FSF/OSI definition.

>
>>     - must be selfcontained
>>
>> * nonfree
>>     - disabled by default, installer will ask to enable it if
>>       it detects hw that need driver/fw from here...
>>     - mirrors must mirror this media to be listed as a mirror
>>     - contains apps/drivers/firmware that are free to redistribute,
>>       but we dont have GPL source for
>>     - for example ati/nvidia drivers/firmware, Oracle Java, ...
>>
>> * tainted
>>     - disabled by default
>>     - mirrors are free to not mirror this media
>>     - stuff we think we can redistribute, but that may have some
>>       patent issues or other restrictions in oter countries.
>
> Merging "codecs" and "firmware" into "tainted" makes sense.
>

actually most firmware we have would end up in core or nonfree

> So "games" and "extra" gets merged back into core (except for non-free games
> of course), won't this make an enormous repos?
>

People seemed to dislike the games splitout, so I "merged" it again

> I think it was better to have a separated games repos, as it will quickly
> get big, and is likely to have frequent backports (as gamers generally want
> to have the latest release).
>

Well, if we want to split out games, it needs atleast:
* games
* games_nonfree

> Would it be possible to have a separate games sub-project, that won't freeze
> to make releases with the rest of mageia?
> Instead it would be an always updating repos which is compiled with the
> latest stable release (or even the previous, if it is possible to have
> packages that install correctly on both).
> The project would only have a "testing" and "release" (or another name to
> avoid confusion with other "release" repos which are frozen), this way you
> could quickly have new versions of all the games, if they don't need
> bleeding-edge libraries (I think they rarely does).
>

Interesting idea, but problem is that if the games are built against 
some newer system libs, they'll stop working on older releases...

--
Thomas