[repoman] moving forward

[Paul Mattal]

So it sounds like we have some rough consensus:

1) Python is good. We'll use Python.

2) Pluggable SCM support is good. Since there's initial interest in at 
least Subversion, GIT, and Mercurial, I think each of me, Dan, and 
Essien should write those plugins, respectively. Once we have a plugin 
interface figured out, of course.

3) DB-OO mapping: it will save us code, and we expect our DB to be 
simple anyway. I vote we use the Django DB layer and apply KISS 
liberally. Django will let us just jump out and do actual SQL if we end 
up needing to, so let's use it where we can and get automatic benefits 
of integration with the main site someday, and not be afraid to jump out 
into SQL for things that are cumbersome in OO land. It will also let us 
use sqlite, mysql, postgres, and a host of other things behind the 
scenes as desired.

4) For initial implementation, we should use sqlite as the DB for 
simplicity and ease of setup.

5) Based on what others have said and my further thinking, my UPL 
(Uniform Package Locator) may not be necessary or helpful. The UPL is 
what the database should be holding behind the scenes for each binary 
package in each binary repo, but we probably don't need to see these 
presented this way.

6) We need to define our terms. Let me try this as a start:

architecture - a single platform, used as an element in the arch=() 
array in a PKGBUILD

version - combination of pkgver and pkgrel, as used in a PKGBUILD

package - a single unit of installable software, identified by pkgname; 
packages have versions and may be built for multiple architectures

binary package - a particular version of a particular package, built for 
a particular architecture

repo (or repository) - a collection of packages, each with a different 
pkgname

binary repo (or binary repository) - a collection of binary packages, 
each with a different package name, all built for the same architecture

tags - a mechanism that existed in CVS which allowed developers to 
specify which specific version of the PKGBUILD was used to build the 
binary package currently in a particular repository; we hope this idea 
will go away, and our database will just specify directly the SCM 
version of a particular PKGBUILD that was used to build the binary 
package currently in a particular repository

7) Based on all this, I will jump in and begin by taking a first crack 
at the Django db model, based on these thoughts and put them in the 
source repository so we can all discuss them and consider changes that 
might be necessary. I will make the db as lightweight as possible, with 
KISS in mind.

I'll probably send another email here soon to hash out some of the model.

- P