[Mageia-sysadm] Starting packages import in Mageia svn

Wed Jan 12 00:34:46 CET 2011

Le mardi 11 janvier 2011 à 18:32 +0100, nicolas vigier a écrit :
+> On Tue, 11 Jan 2011, Thierry Vignaud wrote:
+> 
+> > On 11 January 2011 18:01, nicolas vigier <boklm at mars-attacks.org> wrote:
+> > > After thinking more about this, I think I agree that it would be much
+> > > better to run it on alamut. Especially if using a SQL database for
+> > > packages status.
+> > >
+> > > Maybe once BS is ready, we can work on updating tools to use a database,
+> > > and migrate the web interface on alamut at that time ?
+> > 
+> > That sounds like a the way to go
+> 
+> Actually after talking with blino, he thinks using a database for
+> packages status is not such a good idea :
+> 
+> "we don't need a database, that will only make everything more complex
+> for little advantage..."
+
+It would be easier to clean ( just a select request, referential
+integrity ), easier to code well ( db handle the race condition ).
+And in fact easier to code, ie, if the web team need to handle this, I
+am sure they would prefer using a db than reading output of unix
+command. It would also be easier to interface with others systems, or
+others uses ( statistics, etc ).
+
+It would also be easier to use and understand ( ie, no need to parse
+file and directory structure tied to iurt ). 
+
+Easier to sort, easier to do select ( like showing just the package of a
+maintainer without selecting the whole listing of rpm, and doig lots of
+I/O )
+
+It would spread the load amongst server (I/O wise again), it would use a
+proper indexing system, as the main part of the job of the status page
+is to find the list of job by getting all inodes from some predefined
+directory. 
+
+In short, it seems to me cleaner from a engineering point of view, and
+more extensible.
+
+I understand there is concern on the complexity. But I do not think a
+sql base would be more complex than the current system, where the data
+are encoded partially in the path, partially in the file name, and
+partially in the content of the file. That's not very efficient, and I
+feel that's reinventing the wheel.
+
+Regarding the fact that we lose the ability to do simple shell script, I
+think sql could be much more expressive than shell script when it come
+to data manipulation ( ie, it is partially done for that after all ),
+and that we should first see why we need shell script in the first
+place.
+
+
+Maybe we also do not have the same vision of what would "store stuff in
+db" mean so maybe a more complete proposal could be done.
+
+What about brainstorming about it with a beer at FOSDEM ?
+
+> One advantage is that it's easier to access from an other host (better
+> than nfs export I think). But I don't know if that's enough.
+
+-- 
+Michael Scherer
+
+