Op vrijdag 26 november 2010 22:43:31 schreef Renaud MICHEL: > On vendredi 26 novembre 2010 at 21:29, Thomas Backlund wrote : > > Then we come to the "problematic" part: > > ------ > > x86_64 > > > > media > > > > codecs (disabled by default) > > core (old main+contrib) > > > > backports (disabled by default) > > backports_testing (disabled by default) > > release > > testing (disabled by default) > > updates > > > > extra (unmaintained, disabled by default) > > firmware (disabled by default) > > games (disabled by default) > > non-free (disabled by default) > > /debug_*/ (disabled by default) > > > > ----- > > > > The idea of this layout with some of the separate sections (codecs, > > firmware, games, non-free, debug_*) gives a mirror maintainer in a > > country (or company) the option to exclude the parts they legally (or by > > company policy) can not mirror. > > > > The "core" should be only maintained free/libre stuff so it's easy to > > build a free/libre iso > > > > "extra" is for those packages that no-one really maintain, but is still > > used by someone > > > > "games" are now a separate repo since it can grow fast with a lot of > > game data. > > I think it is a good layout, but, are updates/backports(testing) limited to > core? > > As you mentioned, extra has no reason to have updates or backports, because > if someone did bother to make updates, then the package doesn't belong in > extra. > > For games it would surely be appreciated to have new versions, so maybe a > only a games/updates media which could also be used as a backport media (as > games are not critical). > > For non-free we would probably want also updates and backports, like in > current mandriva. > > Now for firmware and codecs I don't know, are there updates for firmwares? > Maybe they should be in sync with kernel updates (or external modules)? > As for codecs, will it contain anything that could be covered by patents, > like PLF for mandriva? > Does that mean we will still have a stripped down mplayer/xine in core and > a full version in codecs? > But if it is only disabled and you only need to activate it in the control > center to have full featured multimedia programs, it is no big deal, and if > it makes life easier for people whose countries have restrictive law then > we should go for it. > > We should probably have a clear rule to decide what cannot go in core and > should in non-free (that on is pretty clear already) codecs or firmware. > > I hope we will soon get to the point where we will actually put packages in > those repositories :-)
A) i see no reason for codecs and firmware to be separate. However, i do understand that some people would not want to install firmware, but i think we should do this in another way, (like installing a meta package that enforces some limits.) codecs seem odd to be separate, if they have patented problems they should go in non_free, if no problem, they can go in core. B) if they are separate, they would need updates, backports, testing, ... (i expect non_free does too?) C) if they are separate, they cannot be disabled by default, some stuff is needed for stuff to work. D) i have questions about noarch packages, will they be installed on both trees? and if we have more archs later on, more and more? this seems a waste; except if we could hardlink them somehow. if not, we should just put them somewhere separate. E) i understand games to be separate, but disabled by default?, i'm not sure i agree with that. (we need to remember our target audience; stuff needs to work out-of the box) F) what is backports_testing? why can't that just be testing?