[rails3]
name=rails3
baseurl=http://tuxdna.fedorapeople.org/packaging/rubygems/f16/
enabled=1
gpgcheck=0

Now when I installed Rails 3.1.0, I got into a in issue:

$ sudo yum install rubygem-rails-3.1.0
...OUTPUT SKIPPED...
--> Running transaction check
---> Package rubygem-polyglot.noarch 0:0.3.3-1.fc16 will be installed
---> Package rubygem-sprockets.noarch 0:2.0.3-1.fc16 will be installed
--> Processing Dependency: rubygem(tilt) < 1.3.0 for package: rubygem-sprockets-2.0.3-1.fc16.noarch
--> Finished Dependency Resolution
Error: Package: rubygem-sprockets-2.0.3-1.fc16.noarch (psb)
           Requires: rubygem(tilt) < 1.3.0
           Installed: rubygem-tilt-1.3.3-1.fc16.noarch (@psb)
               rubygem(tilt) = 1.3.3
           Available: rubygem-tilt-1.3.2-1.fc16.noarch (fedora)
               rubygem(tilt) = 1.3.2
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

On the surface it seems that rubygem-sprockets wants rubygem-tilt with a version less than 1.3.0 ( we have only 1.3.3 and 1.3.2 available here). However rubygem-sprockets also accepts rubygem-tilt with a version greater than 1.3.0, which is evident from the dependency list:

$ sudo yum deplist rubygem-sprockets-2.0.3-1.fc16.noarch 
Loaded plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit
Finding dependencies: 
package: rubygem-sprockets.noarch 2.0.3-1.fc16
...OUTPUT SKIPPED...
  dependency: rubygem(tilt) >= 1.1
   provider: rubygem-tilt.noarch 1.3.3-1.fc16
  dependency: rubygem(tilt) > 1.3.0
   provider: rubygem-tilt.noarch 1.3.3-1.fc16
  dependency: rubygem(tilt) < 1.3.0
   Unsatisfied dependency
  dependency: rubygem(tilt) < 2
   provider: rubygem-tilt.noarch 1.3.3-1.fc16

To verify that it is actually a problem specific to RPM, I downloaded the RPMs and tried installing with rpm command rather than yum:

$ yumdownloader rubygem-tilt-1.3.3-1.fc16.noarch
$ yumdownloader rubygem-sprockets-2.0.3-1.fc16.noarch
$ ls
rubygem-sprockets-2.0.3-1.fc16.noarch.rpm  rubygem-tilt-1.3.3-1.fc16.noarch.rpm
$ sudo rpm -i rubygem-sprockets-2.0.3-1.fc16.noarch.rpm 
error: Failed dependencies:
	rubygem(hike) >= 1.2 is needed by rubygem-sprockets-2.0.3-1.fc16.noarch
	rubygem(hike) < 2 is needed by rubygem-sprockets-2.0.3-1.fc16.noarch
	rubygem(tilt) < 1.3.0 is needed by rubygem-sprockets-2.0.3-1.fc16.noarch

Cleary RPM doesn’t handle package version intervals well even though the information is available inside the package – rubygem-sprockets requires

rubygem-tilt: >= 1.1, < 1.3.0, > 1.3.0, < 2.0.0

I have RPM version 4.9.1.2 running on Linux 3.2.7-1.fc16.x86_64.

Same arguments apply to Ruby Gems as well. That is to say, Ruby Gems already have a gem command to install and update packages. However it is still not a complete packaging system in itself.

Consider the situation where you need to install a gem called A which dependes on B and C. So you will do:

gem install A

Problem 1: Handling of install failure

This would obviously install the gems in this order B, C and A. It does works for mostly perfect situations. However if C fails to install, “gem” won’t rollback ( i.e. uninstall B ) any steps till C’s failure. This is a problem.

Problem 2: Creating RPM packages with ease

If you ever happen to use Python’s distutils, you will find that it has ability to generate RPM packages from the setup.py itself. Which means an even wider adoption of Python packages.

python setup.py bdist_rpm

What takes for “gem” to support such a functionality? Since creating, installing, packaging and distributing Ruby gems is such a common activity for Ruby developers, I believe such should be available within the standard Ruby distribution.

For now I am using gem2rpm gem which requires a lot of manual intervention. Here is how it works ( as in my earlier post ):


gem fetch rubygem-my-favorite
gem2rpm -s rubygem-my-favorite.gem


Checkout its documentation for more details.

Well it is not just RPM, it could be any package management system ( eg. dpkg, protage etc. ), doesn’t matter as long as it serves the purpose of:

• automatic dependency resolution
• installation of dependencies
• rollback an install step
• install multiple versions of a (JAR) package
• ensure the packages are authentic ( for security )

How is all this achieved in Java world? Simple. Just package all the required JARs in a single JAR or WAR or an EAR for that matter. And trust the packager for its security. But:

• Is this a good practice?
• What happens when you want to install the same package on multiple systems?
• Can you roll back changes easily on multiple installations?
• How are JARs shared across different kind of projects, some which use the same version of the same JAR package?

Consider the case of Maven, with which you can easily specify the dependencies and Maven does all the work of dependency resolution.
However, it solves the problem only at the developer’s level. JARs are still bundled inside the output application package (JAR / WAR / EAR). And everytime this application is distributed, it will contain “ALL” the dependencies. That is clearly an overhead.

That makes me think, why JARs don’t work like Shared Libraries, which can be shared across applications. Every classloader / JVM instance has its own version of the same JAR file on-disk! Can’t they be shared? That too is clearly an overhead. I am not aware of the reasons why it is so, which I would definitely like to know.

The point is, since a package manager has all the functionality, why not just leverage it? Java community is either unaware of it, or doesn’t care.

No problem. There are efforts already in place.

Anyway, of other things Jaikiran told me that, JBoss AS7 has how better and modular class loading which is based on JBoss Modules. This appears to me similar to how Maven structures it JAR repositories.

Here are some resources:

• What is the proper way to package a single jar file as rpm?
• Packaging Java Apps for Ubuntu @ FOSS.IN
• Java Packaging in Fedora
• Creating an RPM for a Java Application
• Maven plugin to create RPM packages

Thats it folks!