Packages: Naming scheme

Its been a while since I wrote a nice article and today I just felt that inner need to write one. Today's topic is an introduction to the naming scheme used to manage packages. But, before that it'll be useful to distinguish between some similar terms.

Package: This is the common name that we generally use. Eg. "Amarok" is a package name
Build: A build is a particular release of a package. eg "Amarok-1.4.12-1.fc10" is a build. Note that a build specification is architecture independent.
RPM: An RPM is the architecture specific binary of a build. Eg. "Amarok-1.4.12-1.fc10.i386.fc10.rpm" is an rpm.
SRPM: Source RPM is architecture independent and contains the sources of the build packaged as an rpm. (Now, why would that be useful, you may ask. Why not a tarball? That'd take up another post to clarify. Queuing the topic)

Naming scheme:
Generally, a build is named in the following manner.
Name-Version-Release (popularly known as the NVR of a package)
Name: might be a simple name such as "Amarok". It can contain the hyphen character.
Version: Version is usually in x.y.z format. "z" being the least significant and "x" being the most significant. Usually, if a respun rpm contains only bug-fixes, only the "z" part is incremented. If there are some major changes or feature additions, "y" is incremented. An architectural change warrants an "x" increment.
But, some packages (like tzdata) use a different versioning scheme. (Since, tzdata package deals with timezone stuff, they find it convenient to include the year in the version. Eg. 2007k, etc.) But, an overwhelming majority use the x.y.z scheme.

Release: It is generally only a decimal number. It can be viewed as the minor version number. If the change is very small, so that incrementing even "z" is unjustified, release number is incremented. It might contain small bugfixes or other minor changes.

When, someone distributes a version of the rpm that deviates from upstream, (he has applied his own patches to the source) he should change the release number to reflect the same. A string is to be appended to the release number.
eg. If someone patches amarok to add his own cool new feature. He has to change the release number from "1" (say), to "1.fa1" or something similar. Just append a string at the end. So, when you see a non-standard package, you can instantly make out from the name.

RPMs also contain the architecture name along with the NVR.

Now, suppose you have 2 packages "blah-1.2.3-1.fc10" and "blah-1.2.3-1.fc11". And, there's a bug-fix which only applies to the fc10 version, what do you do? Certainly, you cannot change the Version number or Release number of the fc10 rpm because it was a "fc10" specific fix and hence, not a property of the build. In such a case, the build is spun as "blah-1.2.3-1.fc10.1". But this is a fairly rare case.


Well, This was a fairly basic post. But, this one merely does the job of heralding a series of posts on messing with RPMs and SRPMs. So, stay tuned!