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!

Writing a resume ...

Resume writing has always been a mystery to me. A rather pointless exercise of listing what you've done in the last 20 years. I mean come on, what does the HR care whether I have secured 40% or 99.99% in the 10th standard? Unless physics and chemistry combine to form a software engineer much like blue and yellow combine to give green. Another thing that has endlessly puzzled me in a resume is "Hobbies". When I was briefly working with the TnP cell (2 hours, before I resigned), I've seen people having such amusing hobbies and the courage to pen them down on the resume. How can "Watching TV" "playing video games" or even "playing pranks" be included in the hobbies section on a resume? Why would the HR give a damn even if you have a hobby of mooning every stranger you see!! Utterly pointless...

But, then my brother gave me this amazing link. (much like the ads where you are fat and the girls are disgusted by you and they always prefer the slim ones and then your friend gives you a pill to make you super-slim within a day) It is titled "Tips for a slightly less awful resume". The author has had a good experience in resume screening. The points he has made clears many of the myths we have about resume writing and to say the least, they are ground-shaking. Whatever I thought were the best practices in resume writing are listed as a strict no-no with a very good line of reasoning. It is a must read for everyone who wants to make that resume of yours slightly less awful.

The post is a bit long and I am, myself very wary of long posts. I generally skip them, if they are not entertaining enough. With this one I was hooked till the last line. The man has got an amazing sense of humour and some really sharp sarcasm. The post isn't a sermon on the do's and don'ts of resume writing but a slightly less awful waste of time on how _not_ to screw-up your resume :)

Please do make it a point to read the post atleast once before you make your "awful" resume! :)