Tagged: rpm Toggle Comment Threads | Keyboard Shortcuts

  • tuxdna 12:48 pm on March 5, 2012 Permalink | Reply
    Tags: rpm,   

    A bug in RPM ? ( for rubygem-sprockets and rubygem-tilt ) 

    I packaged Rails 3.1.0 and its dependencies few days back for Fedora 16. The repository configuration file is as below:

    [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.

     
    • Steven 7:11 pm on March 5, 2012 Permalink | Reply

      I’ve never created an RPM before but it appears obvoius to me that you’ve given RPM an unwinnable condition.

      How is it reasonably supposed to find rubygem-tilt 1.3.0. That logically doesn’t make any sense.

      • Steven 7:13 pm on March 5, 2012 Permalink | Reply

        You’re commenting system broke my last comment. Text magically disappeared from it. I think its the HTML. Why HTML, why?

        How is it reasonably supposed to find rubygem-tilt greater than 1.3.0 and less than 1.3.0 at the same time?

    • tuxdna 7:32 pm on March 5, 2012 Permalink | Reply

      @Steven:
      The Ruby Gem sprockets doesn’t work with tilt version 1.3.0, which is specified as “tilt”, ["~> 1.1", "!= 1.3.0"] in the gem specification https://github.com/sstephenson/sprockets/blob/master/sprockets.gemspec#L16

      There is no equivalent of != of gem specification file in RPM specification file. Hence the less than and greater than. It simply says that, any version of tilt [ from 1.1 to less than 1.3.0 ] or [ greater than 1.3.0 and less than 2.0] is accepted.

      RPM doesn’t treat it well.

      • Steven 7:58 pm on March 5, 2012 Permalink | Reply

        The real issue then is there should be != . You can’t enter in a condition like that and expect a reasonable result from any package manager.

        • tuxdna 8:18 pm on March 5, 2012 Permalink

          I agree that there should be a != for RPM specfile. However != in a sequence would mean less than and greater than. That is a valid way to specify !=.

          What do you think is a solution to this problem?

        • Steven 9:05 pm on March 5, 2012 Permalink

          Let me re-state I’ve written an RPM spec before.

          I would start with this:
          rubygem-tilt: >= 1.1, < 2.0.0

          And then, looking at the documentation, I would simply add version 1.3.0 as a conflict:

          http://www.rpm.org/max-rpm/s1-rpm-depend-manual-dependencies.html#S2-RPM-DEPEND-CONFLICTS-TAG

        • Steven 9:06 pm on March 5, 2012 Permalink

          Sorry, NEVER written an RPM spec file before.

      • tuxdna 7:19 pm on March 7, 2012 Permalink | Reply

        @Steven:
        I checked that adding following line in RPM spec file fixes the issue:
        Conflicts: rubygem(tilt) = 1.3.0

        Thanks for the pointer.

        However, I still feel that RPM should be able to handle the case when version specified are non continuous. Maybe there is some reason its not there, which I would like to know.

        For example there is a proposal for similar problem in Maven:
        http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution

    • Matt Rose 12:53 pm on March 6, 2012 Permalink | Reply

      That’s not a bug in RPM, that’s a bug in gem2rpm. Gem2rpm should be parsing the versions as Steven described. As it is gem2rpm is building an uninstallable rpm

      • tuxdna 7:21 pm on March 7, 2012 Permalink | Reply

        @Matt:
        I disagree, as my viewpoint is different for this problem. Please check my comment above.

        ( or the link below )
        https://tuxdna.wordpress.com/2012/03/05/a-bug-in-rpm-for-rubygem-sprockets-and-rubygem-tilt/#comment-1101

        • Steven Oliver 8:22 pm on March 7, 2012 Permalink

          I think Matt’s right here. This root of this is mathematics more than computer science. Your original line in the RPM spec said that:
          1.3 1.3

          You only have to have an elementary understanding of math to see why that’s not possible. It’s also no coincident that’s why “” is used as the “not equal” symbol in some programming languages.

          If I maintained RPM I would argue that the given tools are sufficient enough to not warrant any changes. Especially in a package like this. Changing the dependency syntax here would possibly require thousands of files to be updated.

          The proposed system you pointed out for Maven looks nice, but it also looks overly complicated.

  • tuxdna 12:12 pm on March 4, 2012 Permalink | Reply
    Tags: rpm, , rubygem   

    Problems with Ruby GEM to RPM 

    I can’t emphasize more the importance of packaging RPMs ( or any other packaging system ), as I already did it in an earlier post.

    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.

     
  • tuxdna 11:00 am on January 27, 2012 Permalink | Reply
    Tags: , packaging, rpm   

    Packaging Java JARs as RPM packages 

    At JUDCon 2012, I had a discussion and argument with Jaikiran Pai and Ravi Maurya on “Packaging Java JARs as RPM packages”.

    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:

    Thats it folks!

     
    • Matěj Cepl 12:14 pm on January 27, 2012 Permalink | Reply

      Would it be possible to create Project Jigsaw packages with some external tools even before the arrival of Java 8?

    • Chaitannya Mahatme 12:53 pm on January 27, 2012 Permalink | Reply

      Yup, I think the Java world doesn’t care, since they have a full-fledged packaging utility. I typically face this issue when working with Eclipse. We are working on debugger. So it’s like I would first launch 2 instance of eclipse, and then in the second instance I would launch another debugger. In this case JVM consumes 1 GB of Ram, otherwise which is normally in the range of 250-300 mb.

      If you look at the plugins (jar packages) which I am using, 90-95% are the same ones. But in this case they have to be launched thrice.

      • Chaitannya Mahatme 12:56 pm on January 27, 2012 Permalink | Reply

        One more thing … I guess Java would lose it’s reputation of build once, run it everywhere if we have a packing system which is native to the OS.

        • tuxdna 12:58 pm on January 27, 2012 Permalink

          Thats a good point. Therefore the packaging mechanism should be platform / OS agnostic.

        • Mohd Asif 9:04 am on February 24, 2012 Permalink

          Lumping all classes in a jar/war/ear is not a packaging utility. java sucks in this regard.
          Its not the reputation which is stopping you to share jars between two running instances. its about security. Java and many other languages runs in a Virtual machine. Each VM is its own world. They dont share anything outside VMs just like a native OS does not share anything with other OS running on other or same hardware.
          To be able to share jars, you should have a common address space where shared data will reside, which is not possible in programs running in different VMs as each VM creates its own address space. In a single JVM, classes are shared between all the threads in most cases which is what should happen.

    • Mohd Asif 8:43 am on February 24, 2012 Permalink | Reply

      Sun microsystems did a shoddy job in creating a dependency specification at jar level. Class is the only unit of functionality. JAR is nothing but a zip of a set of classes. Jar does not declare what all classes/functionality it provides; what is its version; JAR is not annotated with information with what all other jars it need. we get ClassNotFoundException in java and not JarNotFoundException.

      Eclipse foundation’s OSGi/JCP’s Project Jigsaw are trying to solve this problem. Idea is to annotate JARs with all the above information in META-INF so that while loading a JAR you can search all the other supporting jars of right version. That’s what eclipse plugins does. You can install JDT which uses one version of say pluginx.1.0 and than install PDE with pluginx.1.1 Both runs fine.

      Eclipse install new software also resolves all the dependent jars/plugins as well.

      • Matěj Cepl 5:48 am on March 28, 2012 Permalink | Reply

        @Mohd Asif … it is nice and handy, but why Eclipse still asks about restart when OSGI modules should loaded/unloaded while the system is running? And just call all plugin writers idiots, that’s just easy … I suspect OSGI API has some deep warts when nobody is able to use it properly.

        (disclaimer: I am not a Java programmer by any stretch of imagination)

        • Chaitannya Mahatme 6:39 am on March 28, 2012 Permalink

          @Matěj Cepl The Eclipse architecture has a lazy loading feature, i.e. the plugins are loaded only when they are required but all their dependency & contribution related information is collected before hand from the plugin.xml file.

          All the plugin.xml files for all the plugins are loaded only once by equinox when eclipse starts. Hence you need to restart eclipse everytime you add a new plugin.

        • Matěj Cepl 6:44 am on March 28, 2012 Permalink

          OK, so help me … where is the bug?

        • Mohd Asif 7:31 am on March 28, 2012 Permalink

          @Metej : i did not called plugin writers or sunmicrosystems idiots.
          I think you are mixing two different requirements. One is specifying dependency on other so that a package installer pulls dependency jar when dependent jar is installed. Saleem was talking about building such utility in apt/yum etc. OSGi built it in java world.
          The issue you pointed in yours comment is in runtime replacing class from memory so that a newer version of class can be used without a need to restart application. OSGi is not the solution for that.

        • Matěj Cepl 7:40 am on March 28, 2012 Permalink

          I know that the Wikipedia is not the source of The Only Truth, but still I think that “Applications or components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot; ” (the first paragraph of https://en.wikipedia.org/wiki/OSGI) seems like a pretty good advertising of the capability I am missing in Eclipse. But OK, taking your point … owls are not what they seem.

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel
Follow

Get every new post delivered to your Inbox.