From Fedora Project Wiki

(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...')
 
 
(3 intermediate revisions by the same user not shown)
Line 6: Line 6:
==== Defining a KoPeR ====
==== Defining a KoPeR ====


A user would run <code>koji add-personal-repo [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.
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 prevent 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 setup).  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.
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.
'''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 <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 for all rpms under <code>personal-repos/[username]/[repo-name]</code>.  Optionally, <code>repoview</code> 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 <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.

Latest revision as of 16:25, 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 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.