Re: Proposal: using a DBMS for package metadata
seth vidal <[email protected]>
| Newsgroups | gmane.linux.rpm.metadata |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2004-10-01 at 14:13, Jos Vos wrote: > On Fri, Oct 01, 2004 at 05:49:09PM +0200, Luca Barbieri wrote: > > > After reading about the new repomd format, I thought about another > > possible solution to the metadata storage and retrieval problem, that > > may be worth considering and that apparently hasn't been discussed. > > > > The solution consists of putting the repository metadata in a DBMS (such > > as MySQL, PostgreSQL or Firebird), on the main repository server, on > > mirrors and on clients using the same database format. > > I think it is a bad idea, I can't say anything more positive ;-). > > Furthermore, I think already too much simple things are stored in a > RDBMS database in this world, and in this case there are several > additional disadvantages, such as that repositories can't be easily > mirrored and accessed with basic data transfer protocols (http/ftp/rsync) > and that mirror sites' CPU cycles are used and that these sites should > be forced to run/maintain a RDBMS. What Luca described is close to something like rhn. You have a big RDBMS on the backend - an xmlrpc server that the client talks to get dep information as needed. The problems with that are simple - it's hard to get mirrors to put cgis of any type on their systems and it's even harder to make all this be done securely. It's perfectly reasonable to store your metadata in a db of some kind provided you control the only mirror or control ALL the mirrors. it can be potentially very fast, except that you have to design a communication protocol for getting the data from the server(s). -sv