|
|
| (3 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| = Koji Personal Repos =
| | #REDIRECT [[Category:Copr]] |
| | |
| == Overview ==
| |
| Koji Personal Repos (KoPeR) is a concept to allow Fedora maintainers to create personal repos of packages to build against and share with others.
| |
| | |
| === Usage Case ===
| |
| * Bob would like to try out a new version of GTK2. Bob does a koper build of the new GTK2 package, and then builds a number of other packages against this. Bob shares his gtk2newness koper with others for validation of the new GTK2
| |
| | |
| * Jill would like to experiment with rpm using a different compression method for packages. Jill builds a modified version of rpm for her rpm koper and builds a number of other packages with this rpm. Jill shares her rpm koper for further testing of the rpm change.
| |
| | |
| * Dave would like to experiment with kernel patches and have the repo creation handled for him. Dave continues to add patches to kernel source rpms and builds them for his koper(s). Dave shares his various kernel kopers with the community for early testing and validation. Dave spends more time working on kernel and less time dealing with repo management.
| |
| | |
| === Resources ===
| |
| A Fedora maintainer would be alloted up to 1GiB of storage for package repos. Packages can be built for any arch Fedora builds for (but doesn't have to be all of them). koper repos would have repoview content for easy browsing and subscribing to changes.
| |
| | |
| === Work Flow ===
| |
| # Bob requests his account becomes koper capable. | |
| # Bob constructs an srpm of gtk2
| |
| # Bob issues a command (koper build "gtk2newness" gtk2.src.rpm ?) to build the gtk2 package.
| |
| # Koji creates a buildroot based upon the rawhide collection and any packages in Bob's "gtknewness" koper.
| |
| # Koji builds Bob's gtk2
| |
| # $TOOL takes the koji built package and adds it to Bob's "gtknewness" koper, recreating yum repodata and repoview content.
| |
| # Bob proceeds to create srpms for various other packages and builds them in koji against his "gtknewness" koper.
| |
| # Bob shares his "gtknewness" koper with the world
| |
| # Bob creates a Desktop Live image based on rawhide and his "gtknewness" koper and shares that with the world too.
| |
| # Bob fixes bugs with his gtk2 and continues to do builds until everybody is happy
| |
| # Bob commits his gtk2 changes to package SCM and does a normal koji build.
| |
| # Bob profits.
| |
| | |
| === Content ===
| |
| Content within ones koper(s) must be content acceptable for distribution within Fedora.
| |
| | |
| == Changes Needed ==
| |
| To create a koper system various tools in the Fedora infrastructure would need to have changes made to them.
| |
| | |
| === Koji ===
| |
| In order to build packages against a koper, koji would need to gain the ability to reference external yum repos for (at least) scratch builds.
| |
| | |
| === fedorapeople.org ===
| |
| In order to support kopers, fedorapeople.org would need to be able to:
| |
| * Track a separate quota for kopers
| |
| * Accept a signal to recreate repodata and repoview content in kopers
| |
| | |
| === Trademark Guidelines ===
| |
| We'd like to enable people to make development like spins of Fedora that include content from kopers. Since all content in kopers has to adhere to Fedora's guidelines it should be safe. We just need terms in the trademark that allow for this kind of spin creation and sharing so that these people don't have to spend time re-branding and can focus more on development.
| |
| | |
| === New Tools ===
| |
| A few new tools might be needed for dealing with kopers.
| |
| | |
| ==== Tool to build ====
| |
| A script or make target would be needed to initiate a koper build. This is necessary to tell koji what koper to build against, as well as to get the results of the built added to said koper.
| |
| | |
| ==== Tool to add to koper ====
| |
| A tool would be needed to take the koji scratch build output and add it to ones koper, signaling fedorapeople.org to create repodata and repoview content. It should be able to replace older builds of the same package to save quota space. This tool could also be used to add already built packages to an existing koper without having to go through a koji build.
| |
| | |
| == Version 2.0 ==
| |
| Here are some thoughts for future enhancements once we prove that we can walk.
| |
| | |
| * koper groups. Be able to have a group koper that multiple people work on. This should be made as easy as possible to get the most people as possible working together. Start with the idea of open. Extremely useful for feature driven development.
| |
| * koper directory. Have a page off of fedorapeople.org that lists all the (active?) kopers. Easy to walk the filesystem looking for */koper/*. Read from .description files in koper directories for text to display in the directory
| |
| * Autogeneration of koper-repo packages for end users to easily install to use said koper. (or maybe register .repo files with pirut to process?)
| |
| | |
| == Comments ==
| |
| If you wish to leave a comment about this concept, you can do here. I'll try to address them as I can.
| |
| | |
| * MatthiasClasen: The examples make it appear that this is mostly geared towards replacing Fedora packages with own builds. I'd like to see some explanation or guidance on how this will work wrt to versioning (do we require a mandatory suffix for the release, similar to disttags ?). How do we address the concern that bugs reported against such private gtk2 builds will end up in my bugzilla queue ?
| |
| ** JesseKeating: The same things we have in place today for these kinds of things... not much (to begin with). However it really boils down to a consumer education kind of thing, educating the consumers of kopers that they're keeping all the pieces if it breaks and whatnot. The packages obviously wouldn't be signed by a Fedora key so that could be one method of discovery.
| |
| * RussellHarrison: This would be very nice for new packages or packagers. The review process could be streamlined by running some automatic tests (such as rpmlint) on the packages as soon as they're built. Also the ability to use external yum repos would make it much easier to setup a private koji system for making derivative Fedora derived distributions. Say a company internal release or a new live CD.
| |
