[Mageia-dev] Mirror layout, round two

Sat Nov 27 00:02:54 CET 2010

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?
+