Difference between revisions of "Fall 2011 SBR600 Weekly Schedule"
Chris Tyler (talk | contribs) (→Week 2 - Jan 17) |
Chris Tyler (talk | contribs) (→Thursday) |
||
| Line 81: | Line 81: | ||
== Thursday == | == Thursday == | ||
| − | === | + | === Mock: Testing BuildRequires === |
It's often difficult to get the BuildRequires in a spec file exactly right, because it's easy to overlook packages that are coincidentally installed on the machine. ''Mock'' is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones [http://en.wikipedia.org/wiki/Chroot chroot] environment containing only the [[:fedora:Packaging/Guidelines#Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires lines in the spec file. | It's often difficult to get the BuildRequires in a spec file exactly right, because it's easy to overlook packages that are coincidentally installed on the machine. ''Mock'' is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones [http://en.wikipedia.org/wiki/Chroot chroot] environment containing only the [[:fedora:Packaging/Guidelines#Exceptions_2|basic build packages]] plus any packages indicated by BuildRequires lines in the spec file. | ||
| + | |||
| + | === Koji: Testing on Multiple Architectures === | ||
| + | |||
| + | Most developers and packagers have access to only a small number of system architectures (for example, a developer might have access to 64-bit AMD/Intel, but not have access to 32-bit AMD/Intel, s390 mainframe, PowerPC, or ARM systems). The ''Koji'' build system provides a mechanism for building a package in mock on one or more remote systems. | ||
=== To Do === | === To Do === | ||
Revision as of 09:56, 19 January 2012
Please note that the schedule here is tentative. Week-by-week details will be filled in as the course progresses. This content is also being refactored for easier navigation.
Previous semester: Fall 2011 SBR600 Weekly Schedule
Week 1 (Jan 10) - Introduction
Tuesday
Welcome
- About this course
- Introductions
Intro to SBR600 - Software Build & Release
- Brief overview of the Build & Release process
- Introduction to the Fedora Project
- Fedora Project
- Fedora ARM Secondary Architecture project at Seneca and at the Fedora Project
- Course Layout
- Project-based course
- Working with Open Source
- Working with the Fedora Project
- Course Outline
- How this Course Works
- SBR600 Communication Tools
- How coursework is submitted in SBR600
To Do
By Tuesday, January 17:
Week 2 - Jan 17
Tuesday
Using make
Building from Source
- Obtaining source code
- Configuring the build
- Performing the build
- Testing the build
- Installing the built software
RPM Packages
- Differences between managing RPMS and Installing from Source
- RPMS provide a database of installed software
- Let you determine what's installed
- Automatic management of dependencies
- Identify the origin of files
- Permit easy update or removal
- Enable you to verify installation (useful for spotting file corruption and intrusions)
- RPMS provide a database of installed software
- Contents of an RPM Package
The RPM Database
Creating an RPM Package
Resources
- Two simple makefile examples
- Fedora Package Maintainers page
- Fedora Linux chapter 5 (see Seneca Library website > eBooks > View All > Safari > Fedora Linux).
- rpmlint
To Do
By Thursday, January 19:
- Build-from-Source Lab
- RPM-Writing Lab
- Send your SSH public key to your professor so he can create accounts for you on the CDOT Development Systems.
Thursday
Mock: Testing BuildRequires
It's often difficult to get the BuildRequires in a spec file exactly right, because it's easy to overlook packages that are coincidentally installed on the machine. Mock is used to test that the BuildRequires for a package are complete and accurate, by creating a bare-bones chroot environment containing only the basic build packages plus any packages indicated by BuildRequires lines in the spec file.
Koji: Testing on Multiple Architectures
Most developers and packagers have access to only a small number of system architectures (for example, a developer might have access to 64-bit AMD/Intel, but not have access to 32-bit AMD/Intel, s390 mainframe, PowerPC, or ARM systems). The Koji build system provides a mechanism for building a package in mock on one or more remote systems.
To Do
By Tuesday, January 24:
