Talk:JesseKeating/KojiPersonalRepos

Implementation Ideas

Koji Work

Defining a KoPeR

A user would run koji personal-repos --add [repo-name] to create a new repo. This would create a new, empty directory under /mnt/koji/personal-repos/[username]/[repo-name]. There would be a configurable maximum number of KoPeRs any single user would be allowed to create at one time, to prevent people abusing resources. This number would be tracked via the contents of the personal-repos/[username]/ directory, and would not require any schema changes. koji personal-repos --list would list the currently available personal repos.

Building into a KoPeR

All KoPeR builds are by definition scratch builds (otherwise you could just use a regular tag with the appropriate inheritance). To initiate a KoPeR build, a user would run koji build --scratch=[repo-name] [build-target] [SCM-URL-or-srpm-path]. This would tell Koji to add the [repo-name] repo to the mock config for the scratch build, so the contents of the KoPeR would be available as build dependencies.

Question: Should we allow building from any SCM URL? Right now the list of SCM URLs that users are allowed to build from is tightly controlled, even for scratch builds. Theoretically, running a scratch building from an untrusted SCM URL is no more dangerous than running a scratch build of an untrusted srpm, which we currently allow. Should we remove the SCM URL restriction for scratch builds?

When the build is complete, the rpms would be moved to personal-repos/[username]/[repo-name]/[arch]/ according to their arch. If an rpm with the same name is already there, it will be overwritten. A newRepo task will then be initiated to create/regenerate the repodata for all rpms under personal-repos/[username]/[repo-name]. Optionally, repoview data may also be generated.

Question: How do we track the contents of the chroots used for KoPeR builds? Right now even scratch builds have their chroot contents stored in the database, so all rpms in the chroots must either exist in the Koji database or be from a known external repo. We could add each KoPeR repo to the external repos database table, but that would significantly pollute that namespace. Alternately we could stop tracking the contents of the chroot for scratch builds. This would help slow the growth of the buildroot and buildroot_listings tables, and I'm not sure people ever use that data from scratch builds anyway.

Removing a KoPeR

To remove a KoPeR when it is no longer necessary, a user would run koji personal-repos --remove [repo-name]. This would simply remove the personal-repos/[username]/[repo-name] directory and everything underneath it.