Updates from March, 2012 Toggle Comment Threads | Keyboard Shortcuts

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

    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 )
        http://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: , , 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:32 am on March 4, 2012 Permalink | Reply
    Tags: git, libgit2   

    libgit2 now packaged for Fedora 16 

    I just finished a quick packaging of libgit2. It built fine on Koji and can be downloaded from here. A pull request has been submitted to include the spec file in the upstream codebase itself. Rpmfind was of great help in this quick packaging.

     
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.