Infrastructure/PackageDatabase/KojiIntegration

#!html
<div class="document" id="koji-packagedb-interaction">
<h1 class="title">Koji - Packagedb Interaction</h1>
<p>For F7, we're going to have packagers interact with the packagedb.  The packagedb will spawn actions in koji.  For F8, we'll work on integrating the database for the packagedb and the database for koji and a unified front end to access everything.</p>
<div class="section">
<h1><a id="points-of-contact" name="points-of-contact">Points of Contact</a></h1>
<p>These are the tables where koji and the packagedb meet and the differences between them:</p>
<div class="section">
==<a id="packages" name="packages">Packages</a>==
<p>koji:</p>
<pre class="literal-block">
-- by package, we mean srpm
-- we mean the package in general, not an individual build
CREATE TABLE package (
id SERIAL NOT NULL PRIMARY KEY,
name TEXT UNIQUE NOT NULL
) WITHOUT OIDS;

PackageDB:

-- Data associated with an individual package.
--
-- Fields:
-- :id: Unique primary key
-- :name: Name of the package
-- :summary: Brief summary of what the package is
-- :description: Longer description of the package
-- :reviewURL: URL for the review ticket for this package
-- :status: Is the package ready to be built, in review, or other?
create table Package (
id serial primary key,
name text not null unique,
summary text not null,
description text,
reviewURL text,
status integer not null,
foreign key (status) references PackageStatusCode(statusCodeId)
on delete restrict on update cascade
);

<a id="built-packages" name="built-packages">Built Packages</a>

koji:

-- here we track the built packages
-- this is at the srpm level, since builds are by srpm
-- see rpminfo for isolated packages
-- even though we track epoch, we demand that N-V-R be unique
-- task_id: a reference to the task creating the build, may be
--   null, or may point to a deleted task.
CREATE TABLE build (
id SERIAL NOT NULL PRIMARY KEY,
pkg_id INTEGER NOT NULL REFERENCES package (id) DEFERRABLE,
version TEXT NOT NULL,
release TEXT NOT NULL,
epoch INTEGER,
create_event INTEGER NOT NULL REFERENCES events(id) DEFAULT get_event(),
completion_time TIMESTAMP,
state INTEGER NOT NULL,
task_id INTEGER REFERENCES task (id),
owner INTEGER NOT NULL REFERENCES users (id),
CONSTRAINT build_pkg_ver_rel UNIQUE (pkg_id, version, release),
CONSTRAINT completion_sane CHECK ((state = 0 AND completion_time IS NULL) OR
(state != 0 AND completion_time IS NOT NULL))
) WITHOUT OIDS;

PackageDB:

-- Specific version of a package to be built.
--
-- Fields:
-- :id: Easily referenced primary key
-- :packageId: The package this is a specific build of.
-- :epoch: RPM Epoch for this release of the <code>Package</code>.
-- :version: RPM Version string.
-- :release: RPM Release string including any disttag value.
-- :status: What is happening with this particular version.
create table PackageBuild (
id serial not null primary key,
packageId integer not null,
epoch text,
version text not null,
release text not null,
status integer not null,
unique (packageId, epoch, version, release),
foreign key (packageId) references Package(id)
on delete restrict on update cascade,
foreign key (status) references PackageBuildStatusCode(StatusCodeId)
on delete restrict on update cascade
);

<a id="logging" name="logging">Logging</a>

Koji:

CREATE TABLE changelogs (
id SERIAL NOT NULL PRIMARY KEY,
build_id INTEGER NOT NULL REFERENCES build (id),
date TIMESTAMP NOT NULL,
author TEXT NOT NULL,
text TEXT
) WITHOUT OIDS;

The PackageDB logs changes to most tables. Here's the portion that logs changes to the packages:

PackageDB:

-- Log a change to the packageDB.
--
-- Fields:
-- :id: Primary key
-- :userId: Who made the change.
-- :changeTime: Time that the change occurred.
-- :description: Additional information about the change.
create table Log (
id serial primary key,
userId integer not null,
changeTime timestamp default now() not null,
description text
);

-- Log a change made to the Package table.
--
-- Fields:
-- :logId: The id of the log entry.
-- :packageId: The package that changed.
-- :action: What happened to the package.
create table PackageLog (
logId integer primary key,
packageId integer not null,
action integer not null,
foreign key (logId) references Log(id)
on delete cascade on update cascade,
foreign key (packageId) references Package(id)
on delete restrict on update cascade,
foreign key (action) references PackageLogStatusCode (statusCodeId)
on delete restrict on update cascade
);

<a id="tags-collections" name="tags-collections">Tags/Collections</a>

Koji has several tables with information about tags. Need to fill in information about what they do.

The PackageDB has a table for Collections. Then it has Listing tables to associate entities with a collection.

This area needs to be fully looked into.

<a id="notes" name="notes">Notes</a>

These should eventually be better organized.

Koji's primary purpose is to support a buildsystem. It has more information related to that. The PackageDB's primary purpose is to define ownership and permissions related to the Package Sources. The two pieces have some overlap where the sources are handed off to the buildsystem but there doesn't lok to be a whole lot of conflict, rather each piece is concerned with different information about the packages.

We will want to look into replacing Koji's concept of users, groups, and permissions in the long term. The PackageDB ties into the FAS and koji will need to as well. When we do that, we'll need to talk with mikem about how to do it in a generic manner.

Koji has groups that interact with comps -- but I believe it's comps specific to the build system. (ie: not what anaconda sees.) We'll need to look at how that interacts with our plans to use categories for packages and build anaconda comps files from that.