[Mageia-sysadm] Starting packages import in Mageia svn

[Michael Scherer]

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