[repoman] moving forward

[Dan McGee]

On 7/7/07, Paul Mattal <paul at mattal.com> wrote:
> So it sounds like we have some rough consensus:
> 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.

Sounds good to me. Hopefully by the time we get all these written we
will only need the GIT one anyway because I will have you all
converted. :)

> 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

Thanks for the definitions. This should keep us straight down the line.

-Dan