|
| 1 | +RPM-DESIGN(7) |
| 2 | + |
| 3 | +# NAME |
| 4 | +rpm-design - RPM design philosophy |
| 5 | + |
| 6 | +# DESCRIPTION |
| 7 | +RPM is a general purpose software manager. It has |
| 8 | +two major parts: rpmbuild that combines upstream sources with a meta |
| 9 | +data and build instructions in a "spec file" and additional files and |
| 10 | +patches. It allows to bundle all this up into a source package and |
| 11 | +build the software into a binary package. The second part - the rpm |
| 12 | +utility - can then install, update or remove the packages after |
| 13 | +checking for consistency. |
| 14 | + |
| 15 | +## Design goals |
| 16 | +- General purpose software management |
| 17 | +- Building from pristine sources |
| 18 | +- Unattended operation |
| 19 | + - for building packages |
| 20 | + - for installing/updating/deleting packages |
| 21 | +- Reproducibility of builds and installs |
| 22 | +- Verifiability of packages and installed software |
| 23 | + |
| 24 | +## General purpose software management |
| 25 | +RPM differs from special purpose package managers - like those |
| 26 | +targeting a specific programming language - in trying to not make |
| 27 | +assumptions about how software looks like or gets packaged. Packaging |
| 28 | +software can be messy and RPM accommodates for that. |
| 29 | + |
| 30 | +It still offers help to create a POSIX-like operation system. Macros |
| 31 | +parameterize locations to make the build instructions more generic and |
| 32 | +more easily transferable between distributions. Nevertheless RPM |
| 33 | +packages are targeting a specific distribution (and release thereof). They are |
| 34 | +typically not suited to be installed or even built elsewhere without |
| 35 | +tweaking. RPM acknowledges that different distributions have |
| 36 | +different goals, resulting in different design decisions. The |
| 37 | +specifics of the packages often reflect these. |
| 38 | + |
| 39 | +RPM as a upstream project still tries to keep distributions from |
| 40 | +diverging unnecessarily but is aware that these differences are the |
| 41 | +reason distributions exist in the first place. |
| 42 | + |
| 43 | +## Rolling out (security) updates quickly |
| 44 | +Getting updates installed quickly is one of the main design |
| 45 | +goals. Many features and following design decisions are supporting |
| 46 | +this goal. |
| 47 | + |
| 48 | +## Packaging dependencies separately |
| 49 | +Libraries should be packaged separately and binaries should link to |
| 50 | +the version provided by system packages. Static linking is |
| 51 | +discouraged. This limits the number of packages that need updates or |
| 52 | +re-builds in case of a vulnerability. |
| 53 | + |
| 54 | +## Unattended operation |
| 55 | +Package installation and update is unattended and must not require |
| 56 | +user interaction. This allows automatically installing security - and |
| 57 | +other - updates. |
| 58 | + |
| 59 | +Building the packages also runs unattended. This prevents user input |
| 60 | +from changing the output but also makes rebuilding packages - e.g. for |
| 61 | +changed dependencies - possible at large scale. |
| 62 | + |
| 63 | +## Clear update path |
| 64 | +Each package name creates an update path where packages with the same |
| 65 | +name and a newer version (technically Epoch-Version-Release) are an |
| 66 | +update for the packages with lower version. Packages are not allowed |
| 67 | +to make assumptions on what intermediate packages were installed or |
| 68 | +not. |
| 69 | + |
| 70 | +## Bundle Sources, Changes and Build instructions together |
| 71 | +Source packages bundle upstream sources, patches and build |
| 72 | +instructions into one entity. If changes need to be made everything |
| 73 | +needed is available, including a list of packages needed to run the |
| 74 | +build. |
| 75 | + |
| 76 | +## Separate Upstream Source from Patches |
| 77 | +Source packages are supposed to contain the unaltered upstream sources |
| 78 | +in a way that their checksum can be checked. All changes can be done |
| 79 | +by applying patches or running build scripts. This makes it easy to |
| 80 | +understand what the packager did to the software. This is important to |
| 81 | +be able to figure out where issues arise from and to see which issues |
| 82 | +are fixed in the package - even if the upstream version is still |
| 83 | +vulnerable. |
| 84 | + |
| 85 | +## Support backporting fixes |
| 86 | +A distribution often has a different approach to fixing software from an |
| 87 | +upstream project. Upstream projects are often content with fixing |
| 88 | +their latest release(s). Distribution often support a particular |
| 89 | +version of each software and need those to be fixed. The Sources and |
| 90 | +Patches approach makes handling this a lot easier (although it is |
| 91 | +lately being extended with the use of version control like *git*(1)). |
| 92 | + |
| 93 | +## Allow 3rd party packages |
| 94 | +Although RPM is designed to package a whole distribution it explicitly |
| 95 | +supports 3rd parties to also provide packages without becoming part of |
| 96 | +the distribution and their processes. |
| 97 | + |
| 98 | +Rpmbuild can be run locally without the use of a big build |
| 99 | +system. Dependencies are in large part automatic and target libraries |
| 100 | +inside the packages instead of relying on conventions like package |
| 101 | +names. This way 3rd party packages can be checked for compatibility |
| 102 | +beyond them just claiming that they target the distribution in question. |
| 103 | + |
| 104 | +For proprietary softerware nosource packages allow to not ship the |
| 105 | +sources but only the build instructions to keep proprietary source |
| 106 | +private. They still can be used to generate binary packages in |
| 107 | +combination with the sources. |
| 108 | + |
| 109 | +## Handle all system files |
| 110 | +RPM takes ownership of all system files and their life cycle. While |
| 111 | +packages can copy files in their scriptlets at installation time this |
| 112 | +is strongly discouraged. Even files that are not actually shipped can |
| 113 | +be added to the package as *%ghost* files to allow RPM to handle |
| 114 | +them. All system files and directories should be owned by a package. |
| 115 | + |
| 116 | +Scriptlets should be used sparingly. Most use cases - like updating |
| 117 | +caches and indexes - can be dealt with by using a central |
| 118 | +filetrigger. Although these files may get altered they still should be |
| 119 | +owned by a package. |
| 120 | + |
| 121 | +## Verify files |
| 122 | +RPM keeps checksums of all files it maintains. Packages have checksums |
| 123 | +and can and should be signed. Files that need to change on disk - like |
| 124 | +config files, databases or indexes - can be marked and are treated |
| 125 | +differently when being changed. While unchange config files may be |
| 126 | +replaced changed ones will be retained or backed up - depending on the |
| 127 | +way they have been packaged. |
| 128 | + |
| 129 | +## RPM in the Software handling stack |
| 130 | +RPM sees itself as filling specific layers in the software handling |
| 131 | +stack. It relies on build systems like make and the upstream provided |
| 132 | +build scripts to orchestrate the actual build and passes the acquiring |
| 133 | +and selection of the "right" packages up to updaters like *yum*(8), *dnf*(8), |
| 134 | +*zypper*(8), etc. |
| 135 | + |
| 136 | +The stack typically looks like this: |
| 137 | +- Upstream build scripts using tools like maker, cmake, ant, ... |
| 138 | +- rpmbuild for running those via an *rpm-spec*(5) file |
| 139 | +- Build systems for installing build dependencies and keeping track of build artifacts |
| 140 | +- Package repositories offering binary packages |
| 141 | +- Installers/Updaters selecting and downloading packages |
| 142 | +- rpm checking for consistency and installing/updating the packages |
| 143 | + |
| 144 | +As such RPM is only a part in a larger set of tools and some users may |
| 145 | +never actually interact with RPM directly. |
| 146 | + |
| 147 | +## Levels of control |
| 148 | +Most things in RPM can be configured by macros. This allows different |
| 149 | +actors to set them and overwrite what was set previously. |
| 150 | + |
| 151 | +Most basic are the defaults delivered by RPM upstream. Distributions |
| 152 | +are able to overwrite them by patching or providing new macro |
| 153 | +files. Packages can also ship macro files for other packages to use as |
| 154 | +BuildRequires. Finally most build related macros can also be |
| 155 | +overwritten in the *rpm-spec*(5) file - giving the packager the last word. |
| 156 | + |
| 157 | +There are a few command line options to allow users to influence how |
| 158 | +packages are installed but their use is discouraged for the most part |
| 159 | +and packages should be installed as they are. |
| 160 | + |
| 161 | +# SEE ALSO |
| 162 | +*rpm*(8) *rpmbuild*(1) *rpm-spec*(5) *rpm-macros*(7) *rpm-scriptlets*(7) |
| 163 | + |
| 164 | +*http://www.rpm.org/* |
0 commit comments