Difference between revisions of "DPI908/SBR600 Repo Creation Lab"
Chris Tyler (talk | contribs) (Created page with 'Category:DPI908/SBR600 Labs = Purpose = To learn how to create a repository. = Background Resources = Signing and Creating a Repository for RPM Packages = Required Re…') |
Chris Tyler (talk | contribs) (→Deliverable) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[Category:DPI908/SBR600 Labs]] | + | [[Category:DPI908/SBR600 Labs]][[Category: SBR600 Labs]] |
= Purpose = | = Purpose = | ||
| − | To learn how to create a repository. | + | To learn how to create a RPM package repository for use with <code>yum</code>. |
= Background Resources = | = Background Resources = | ||
| Line 34: | Line 34: | ||
== Create a Release File == | == Create a Release File == | ||
| − | # A release package makes it easy for people to get software from your repository. Create a release package as | + | # A release package makes it easy for people to get software from your repository. Create a release package as mentioned in the [[Signing and Creating a Repository for RPM Packages]] page. |
| − | [[Signing and Creating a Repository for RPM Packages]] page. | ||
{{Admon/tip|Hint: Reusing Packages|The easiest way to create a release package is to take and modify an existing release package. Get the source RPM for the RPM Fusion release package, install it, and edit it to meet your needs. Remember: when working with open source, don't re-invent the wheel unnecessarily!}} | {{Admon/tip|Hint: Reusing Packages|The easiest way to create a release package is to take and modify an existing release package. Get the source RPM for the RPM Fusion release package, install it, and edit it to meet your needs. Remember: when working with open source, don't re-invent the wheel unnecessarily!}} | ||
| Line 43: | Line 42: | ||
Create a blog post describing your experience. Include: | Create a blog post describing your experience. Include: | ||
* Notes on what you did, and what worked and didn't work. | * Notes on what you did, and what worked and didn't work. | ||
| − | * The results, including a link to your release package. | + | * The results, including a link to your release package and your repository. |
* Your reflections on the tools, process, and experience. | * Your reflections on the tools, process, and experience. | ||
Latest revision as of 00:12, 19 September 2013
Contents
Purpose
To learn how to create a RPM package repository for use with yum.
Background Resources
Signing and Creating a Repository for RPM Packages
Required Resources
Before starting this lab, you will need:
- The RPMs from the previous lab.
- An account on a system that can serve files to the web (http or ftp).
Preparation
- Check that you have the
createrepopackage installed.
Steps
Creating the Repository
- Place the signed RPMs in a directory on your Fedora system.
- Run this command:
createrepo . - Make a note of the subdirectory and file created by the previous step.
- Make the files available via the web (copy to the appropriate system and directory).
Creating the Repo and Key Files
- Create the repo and key files as outlined on the Signing and Creating a Repository for RPM Packages page.
- Test that they work as expected.
Create a Release File
- A release package makes it easy for people to get software from your repository. Create a release package as mentioned in the Signing and Creating a Repository for RPM Packages page.
Hint: Reusing Packages
The easiest way to create a release package is to take and modify an existing release package. Get the source RPM for the RPM Fusion release package, install it, and edit it to meet your needs. Remember: when working with open source, don't re-invent the wheel unnecessarily!
The easiest way to create a release package is to take and modify an existing release package. Get the source RPM for the RPM Fusion release package, install it, and edit it to meet your needs. Remember: when working with open source, don't re-invent the wheel unnecessarily!
Deliverable
Create a blog post describing your experience. Include:
- Notes on what you did, and what worked and didn't work.
- The results, including a link to your release package and your repository.
- Your reflections on the tools, process, and experience.
