Red Hat Requirements Doug Ledford

1. Red Hat Requirements Doug Ledford

2. RPM packaging really matters System installation/updates rely upon proper RPM packaging for: Dependency resolution Automatic simultaneous updates of related packages Coordination of ownership of directories and files Conflict resolution Red Hat package build systems require: Repeatable, deterministic builds Exact source code management No two builds have the same name, version, release combination Given any name, version, release combination, we must be able to pinpoint the exact binary files, the exact source used to build the binary files, and know the exact build environment used to build the files

3. RPM packaging really matters (cont.) Red Hat package guidelines require: All packages must adhere to the Linux File Hierarchy Standard http://www.pathname.com/fhs/ All packages should follow the relevant package guidelines from the Fedora Project http://fedoraproject.org/wiki/PackageMaintainers See the Packaging and Resources for Fedora Package Collection Contributors sections for lots of useful information From OFED 1.0 to OFED 1.2, the following has been true: Package count has increased Old packages that didn't follow the relevant guidelines necessary to ease integration into RHEL still don't follow those guidelines Newly added packages also don't follow those guidelines Time to integrate each successive release of OFED into RHEL has increased

4. Example RPM packaging issues Lack of official code releases in most projects: branches such as master exist, but master may have multiple distinct releases present, and in some cases there will be symbolic tags for the releases and in some cases not While interdependencies from one repo to another on specific features could be codified via statements in spec files, they usually are not (aka, the spec file for OpenMPI 1.2.1, which supports the new fork() symantics in libibverbs 1.1, should have a BuildRequires: libibverbs >= 1.1 to represent the dependency in a machine checkable fashion) RPM packages should build to the standard locations and options without needing to pass anything to the rpmbuild command (required by automated build systems) Different binary RPMs should be built from different source RPMs Modification of files owned by other RPMs during %post scripts is verboten Hand rolling backups in %post scripts is verboten (RPM can already do rollback RPMs for you, but you have to have a reasonable RPM first)

5. Suggested actions to remedy issues Standardize, standardize, standardize File locations MPI alternatives coexistence issues /etc config file locations/names Arch specific multilib support issues Do it NOW, before the problem gets worse Split up the single large RPMs into smaller RPMs for specific components Implement planned releases of specific components Have maintainers create Fedora project accounts and submit RPMs for specific components to Fedora Have maintainers undergo the Fedora Review Process for packages Make whichever of these steps the OFA decides to follow release blockers for the next OFED release

6. Example git cleanup An example revamp of the management git tree was completed to illustrate changes. To see the changes: git clone git://git.openfabrics.org/~dledford/management cd management git pull origin master:master git log master..

7. Example git cleanup (cont.) After these changes, the management tree can have daily releases be built through the Fedora build system with just the following script: cd ~/upstream/management ./make.dist daily for i in libibcommon libibumad libibmad opensm openib-diags; do cd ~/extrascvs/$i/devel cp ~/upstream/management/dist/$i-git.tgz . tar -xzf ${i}-git.tgz $i/$i.spec mv $i/$i.spec . make FILES=$i-git.tgz upload cvs ci -m “Updated daily git build of $i” make tag make build done An official release is only slightly different due to a different tarball name

8. Benefits of Fedora package ownership First and foremost, it puts the developer in control of integration. No more waiting for Red Hat to get it done. The Fedora community doesn't just require the packages to have a bunch of Fedora specific cruft. The Fedora requirements are generally applicable to and wise for all distributions. Therefore, putting the packages through the Fedora review process makes them better for all distributions. The Fedora build system allows you to spit out pre-built binaries for all supported architectures from a single build command. The packages will be accessible to all interested parties via yum, the Fedora system updater. No more need to distribute the binary packages (for Fedora anyway) as the distribution mechanism is built into Fedora and the build system. Integration of packages from Fedora into RHEL is generally automatic. Once the Fedora review process has been completed and the packages cleaned up, the job is done and the developer can concentrate on coding from that point on.

9. Wrap-Up Maintainers interested in Fedora build system access http://fedoraproject.org/wiki/PackageMaintainers/Join Talk to me, I'll help get you set up and answer any questions you have