[Mageia-dev] Mirror layout, round two

Fri Dec 3 06:07:27 CET 2010

Maarten Vanraes a écrit :
+>
+> Op donderdag 02 december 2010 08:20:15 schreef andre999:
+>> Maarten Vanraes a écrit :
+>>> Op woensdag 01 december 2010 21:54:48 schreef andre999:
+>>> [...]
+>>
+>>> i also see that mirror layout should be as easy as possible for mirror
+>>> admins.
+>>
+>> Agreed.  However keeping an extra set of repositories for core packages
+>> would just add a few extra directories (without changing the number/size
+>> of their total content), thus have little impact on mirror administration.
+>
+> One would think so; however, a few people who replied where mirror
+> administrators; and it seems, IIUC that they said it does have impact.
+>
+> I'm just gonna trust their judgement on this, since they know more about this
+> than myself.
+
+Mageia requires mirror sites to use rsync for mirroring.
+Mirroring at least every few hours, if I remember correctly.  (I forget 
+the other details.)
+
+They need a single line of code, something like
+
+rsync -ra {URL-source-directory} {local-destination-directory}
+
+This is very easy to do : Mageia gives the source URL (and the options 
+required), and the mirror site knows the destination directory.
+
+This line of code is put in a cron (or acron) job file, configured to 
+run automatically at the specified regular intervals.
+
+If they exclude the optional "tainted" repositories, they have to add an 
+"--exclude" option with the relative path to these repositories.
+(Still in a single line.)
+Fairly straight-forward.
+
+Why system admins in multi-mirror sites with lots of other tasks would 
+like to avoid optional repositories is that they are probably already 
+overloaded with things to do, and adding the exclusion multiplies the 
+risk of having a (tiny) error that makes it not work.
+Also, a minor change at the Mageia source could make it stop working.
+The last thing they need is another problem.
+
+> [...]
+>>
+>> Note that if, down the road, we find another effective method for
+>> distinquishing core / non-core, it is relatively simple to transfer
+>> packages in "extra" to "core".
+>> But if we eliminate the parallel set of repositories, and find later
+>> that we have a problem giving priority to core packages, moving in the
+>> other direction would be a much more difficult process.
+>
+> IIRC someone with experience said in this thread that we could always go to
+> that sort of scenario if like this it wouldn't work well. Again, i'm gonna
+> trust their judgement on this.
+
+( At least some things said in this thread seem to me more in the line 
+of wishful thinking.  A bit like "I'm not planning to have an accident, 
+so why do I need a seat belt ?" )
+
+I still think it would be better to later remove than add.
+The main problem is that without the separation by repositories, in 
+order to ensure full support for core modules, we would need another 
+control.
+If we start with separate sets of repositories, that control is already 
+there - removing the complication of adding some other control in 
+setting up the system.
+Maybe we can find a way of setting up a reliable such control in the 
+build system without a too much effort.  But it is more effort, subject 
+to debugging, etc, as with any new code.
+
+regards
+
+- André
+