(Created page with ' == Implementation Ideas == === Koji Work === ==== Defining a KoPeR ==== A user would run <code>koji add-personal-repo [repo-name]</code> to create a new repo. This would cre...') |
|||
| Line 6: | Line 6: | ||
==== Defining a KoPeR ==== | ==== Defining a KoPeR ==== | ||
A user would run <code>koji | A user would run <code>koji personal-repos --add [repo-name]</code> to create a new repo. This would create a new, empty directory under <code>/mnt/koji/personal-repos/[username]/[repo-name]</code>. There would be a configurable maximum number of KoPeRs any single user would be allowed to create at one time, to avoid people abusing resources. This number would be tracked via the contents of the <code>personal-repos/[username]/</code> directory, and would not require any schema changes. <code>koji personal-repos --list</code> would list the currently available personal repos. | ||
==== Building into a KoPeR ==== | ==== Building into a KoPeR ==== | ||
All KoPeR builds are by definition scratch builds (otherwise you could just use a regular tag with the appropriate inheritance | 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 <code>koji build --scratch=[repo-name] [build-target] [SCM-URL-or-srpm-path]</code>. This would tell Koji to add the <code>[repo-name]</code> repo to the mock config for the scratch build, so the contents of the KoPeR would be available as build dependencies. | ||
When the build is complete, the rpms would be moved to <code>personal-repos/[username]/[repo-name]/[arch]/</code> 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 all rpms under <code>personal-repos/[username]/[repo-name]</code>. Optionally, <code>repoview</code> data may also be generated. | When the build is complete, the rpms would be moved to <code>personal-repos/[username]/[repo-name]/[arch]/</code> according to their arch. If an rpm with the same name is already there, it will be overwritten. A <code>newRepo</code> task will then be initiated to create/regenerate the repodata all rpms under <code>personal-repos/[username]/[repo-name]</code>. Optionally, <code>repoview</code> data may also be generated. | ||
Issue: 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 <code>koji personal-repos --remove [repo-name]</code>. This would simply remove the <code>personal-repos/[username]/[repo-name]</code> directory and everything underneath it. | |||
Revision as of 16:11, 11 March 2010
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 avoid 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.
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 all rpms under personal-repos/[username]/[repo-name]. Optionally, repoview data may also be generated.
Issue: 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.