CDE - An Innovative Way Of Running Programs On Diverse Linux Machines

CDE (not to be mistaken for the Common Desktop Environment in UNIX) is a packaging tool which allows you to identically replicate the execution of a program running on one Linux machine, on to another.

It does this by packaging up the Code, Data, and Environment (including all the dependencies - libraries, auxiliary programs etc) together, which can then be transferred and executed flawlessly on a different Linux machine.
Read more »

RPM 5.0 released

RPM is a powerful and mature command-line driven package management system capable of installing, uninstalling, verifying, querying, and updating Unix/Linux software packages. Each software package consists of an archive of files along with information about the package like its version, a description, and the like. [ For a short introduction to using RPM check out this guide ].

Exactly 12 months back, I had posted the good news of plans to revamp RPM.

New features in RPM 5.0

• The Automake/Autoconf/Libtool-based build environment of RPM was completely revamped from scratch.
• Configuration is now through RPM macros during run time instead of through rpmrc.
• The RPM code base was ported to all major platforms, including the BSD, Linux, Solaris and Mac OS X Unix flavors and Windows/Cygwin.
• RPM packages now also support LZMA compression apart from Gzip and Bzip2.
• RPM is now able to automatically track vendor distribution files with its new vcheck(1) based "%track" section and now can automatically download the vendor distribution files too. (Does this translate to automatic dependency resolution ?)
  

Read the official press release here.

Ubuntu sources.list online generator

I have faced a number of times the prospect of entering the web address of the online repositories just because I some how tampered the contents of the sources.list file which is residing in /etc/apt/ location. Agreed, it is not difficult to fire up ones favorite editor and enter a bunch of lines by hand. But then it would be nice to have a tool which creates the code to be entered in your sources.list file automatically.

More specifically if the tool resides online, you can access it anywhere. Enter the Ubuntu sources.list online generator. The USP of this unique online tool is that you can create your own custom sources.list from various available sources and it takes only two simple steps.

So next time you are faced with re-building your sources.list file in Ubuntu, visit the Ubuntu sources.list generator and populate your sources.list file.

Related articles :
Using netselect-apt - Tip to select the fastest Debian mirror.
A Concise apt-get / dpkg primer - For new Debian users.
A list of Ubuntu/Kubuntu repositories

apt-pinning - Configuring Debian to run the latest packages

The first time I installed and tried out Debian Linux distribution, I was surprised by the different way of configuring it which included the placement of configuration files, the change in commands used and so on. Coming from a Red Hat background and tuned to the Red Hat way of doing things, I did have some learning curve to overcome.

But once I mastered how to configure things in Debian, I realised that I liked the Debian way of doing things much more than the Red Hat way. But one thing which really put me off was that Debian installed the antiquated packages of the software I use on a daily basis. And I needed something more recent. I explored how to install the cutting edge of software of my choice in Debian and I did get quite a few suggestions from various quarters including one of incorporating backports repository in the distribution.

But none told me about Apt-Pinning - the process of mixing and matching between stable, unstable and testing repositories to get a stable Debian distribution which also ran the latest version of ones software. And because I was largely unsuccessful in my endeavour of getting the latest version of software running on Debian stable, I switched to Ubuntu.

I recently came across this lucid tutorial written by John.H.Robinson called "Apt-Pinning for Beginners", which explains the process in very clear terms. If I had come across this tutorial earlier, I would still have been using Debian on my PC.

RPM Package Manager

RPM is a recursive acronym for RPM Package Manager (Formerly known as Redhat Package Manager). It is the default package manager in RedHat as well as RedHat based Linux distributions like Mandrake, OpenSuSE, PCLinuxOS and so on [Read about these Linux distributions here ]. It is very powerful and can be used to install, remove, update software, as well as a whole lot of other things in Linux. Basically, RPM can be divided into 3 main areas of functionality.

1. Packages - Files that are compressed and contain applications, data and other files.
2. Database - A list of installed packages in a system.
3. Compilation - Bundling a bunch of files into a package suitable for installation on other systems.
   

Here are a couple of important RPM commands that are frequently used by Linux users though now a days, they use other tools (such as Yum) which provide automatic dependency checking to achieve the same.

Querying - Know more about a package

You can query the RPM database to know more details about a particular package that is installed in your system. To see if a particular program (say gedit, a text editor) is installed or not, use -q to activate the query mode in RPM.

# rpm -q gedit

RPM usually responds with the name, version and release of the package installed or, more likely reports that it is not present. To see all the files that are installed for gedit and their full path, use the -l sub parameter with the query mode.

# rpm -q -l gedit

Here -q is the mode and -l is the submode. Usually you can bundle the mode and sub-mode parameters together as follows:

# rpm -ql gedit

You can also try...

# rpm -qlv gedit

... for a more verbose output.

To find, in which package the file /bin/sh is located, try :

# rpm -qf /bin/sh
 bash-2.05b-38

...which tells that the file /bin/sh is situated in the package bash-2.05b-38.
Now to get more details about the bash package execute the following command:

# rpm -qi bash

...which will give a whole lot of details about the bash package installed in your system.

Installing and removing packages

Suppose you want to install a package (say gedit):

# rpm -ivh gedit-2.6.0-4.rpm

To update gedit to a newer version:

# rpm -Uvh gedit-2.8.0-6.rpm

The -U mode means, if this package is not installed, install it; if an older version of this package is installed, upgrade it.

There is a third installation mode, called freshening, represented by -F. This is similar to -U in that it upgrades a package that is installed, but it adds one restriction - it ignores any packages that are not of the same name as a package that is already installed on your system. So if you have a directory containing a bundle of rpms - say security patches - then you can move into that directory containing the security patches in RPM format and execute the command:

# rpm -Fvh *.rpm

... which will install only those security patches which are related to the packages that are already installed in your system and will ignore the rest.

To remove an already installed package say gedit, just type:

# rpm -e gedit

Drawbacks of RPM

RPM has one difficulty, ie it will not install a package if that package depends on another program that is not already installed on your system. This is known as a dependency issue. RedHat provides two utilities called rpmdb-redhat for RedHat enterprise linux and rpmdb-fedora for Fedora Core. Once you install one of these on your system, RPM will automatically begin suggesting dependency resolutions.

Of course, you can force RPM to install a package even without resolving a dependency problem by using the --force and --nodeps parameters to both the installation related modes and the remove mode. They ignore conflicts and dependencies respectively.

Suppose you do not want to install an RPM package but get one or more files in it. You can use a utility called rpm2cpio to convert your RPM package into a cpio package (which is more or less similar to a tarball) then use the command cpio to extract all the files into a directory as follows:

# rpm2cpio PackageName | cpio -id

This will extract all the files from the RPM package into the current directory. This is only a small subset of the power of RPM. To know more about it try:

# man rpm