1. 1 April 2, 2008 1 Software Packaging and Releasing Best Practices William Cohen NCSU CSC 591W April 2, 2008

2. 2 2 Source Tarball ● Tag to check out source for release from code repository ● All files in tarball should in code repository: ● No locally created files in tarball ● Tarball creates single directory with everything inside single directory ● Tarball name matches directory created, e.g. oprofile-0.9.3.tar.gz creat directory oprofile-0.9.3 ● Use compression, text files in source compress well

3. 3 April 2, 2008 3 Source Tarball Contents ● Clear license information ● Install: ● List requirement for building software ● Instructions to build ● Readme: ● Pointer to project page for additional information and help ● Complete source code: ● Okay to depend on other projects ● Avoid putting copies of other project's source files into code

4. 4 April 2, 2008 4 Source Building ● Describe in the INSTALL file ● Keep it simple: ●./configure – setup options ● make – build the software ● make install – places software in proper locations ● Configure, build and install are separate steps ● Only the install should need root privileges ● Do not hard code location of build and install destination

5. 5 April 2, 2008 5 Distribution Packaging

6. 6 April 2, 2008 6 Naming ● Names of source rpm and generated rpms should match up ● May have subpackages, for example gcc-c++-4.1.2-33 ● Dash '-' used to delimit parts of NVR ● Unique names, each name identifies a single package ● Version numbering so upgrades work properly: ● Snapshot, alpha, beta, and release candidates: ● kernel-2.6.25-rc7 becomes kernel-2.6.25-0.185rc7

7. 7 April 2, 2008 7 Summary and Description ● Summary field provides one line description of what package is ● Description field provides a paragraph ● Keep the lines less than 80 characters in length ● For more detailed information people should refer to th documentation

8. 8 April 2, 2008 8 URL, Source, and Patches ● URL: entry ● Points to the project page ● Verify correct and up to date ● Source: entry ● Points to location for pristine source ● Verify correct an up to date ● Use patches for any modifications on source ● Patch n : entries ● Patches to apply to pristine source

9. 9 April 2, 2008 9 Licensing ● RPM License: entry ● Reference to the license of the resulting binary RPM ● Make sure that the field is accurate ● List of concise names for licenses: ● http://fedoraproject.org/wiki/Licensing http://fedoraproject.org/wiki/Licensing

10. 10 April 2, 2008 10 Avoid Binaries or Libraries in Source RPM ● Security Issues: ● Cannot check the security of a binary ● Cannot generate patches for a binary ● Compiler: ● Code compile with specific flags, e.g. Fortify option ● ABI and library changes ● Possible exceptions: ● Cross compiled code ● Firmware

11. 11 April 2, 2008 11 Changelogs ● Describe what has changed in the rpm ● Include the version information so easy to know which build has change ● Include what specific bugs fixed

12. 12 April 2, 2008 12 Static Libraries ● Avoid static libraries ● Cannot determine which packages use static library ● When correction made in static library do not know what other packages need to be rebuild ● Use shared libraries instead, automatic use of new and improved code

13. 13 April 2, 2008 13 Dependencies ● State the dependencies required to build package builds and for package to operates properly ● Used by build systems to set up build environment ● BuildRequires: ● Things needed when the binary rpm built from srpm ● With autoconfig can have things in the binary rpm differ depending on build environment ● Requires: ● Things needed for binary rpm ● RPM figures out dependencies on shared libraries when building

14. 14 April 2, 2008 14 Documentation ● Not everyone needs/wants the documentation ● Consider putting documentation into subpackage if very large

15. 15 April 2, 2008 15 Desktop/GUI Applications ● Do not want to start via command line ● Need to have icon and entry so menu item available

16. 16 April 2, 2008 16 Packaging Sanity Checks ● Compare with earlier packaging ● Files: ● Ownership and permissions ● Size ● Added, deleted, or moved ● Proper requires/provides

17. 17 April 2, 2008 17 Building the RPM ● Avoid building rpms as root ● Use the rpm macro (~/.rpmmacros): %home %(echo $HOME) %_topdir %{home}/rh-rpms

18. 18 April 2, 2008 18 Rpmlint ● Handy script to look for possible problems

19. 19 April 2, 2008 19 Further Reading ● http://fedoraproject.org/wiki/Packaging/Guidelines http://fedoraproject.org/wiki/Packaging/Guidelines ● http://linux.die.net/man/1/rpmlint http://linux.die.net/man/1/rpmlint ● http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-packaging- guidelines.html http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-packaging- guidelines.html ● http://www.debian.org/doc/debian-policy/ http://www.debian.org/doc/debian-policy/