November 2012 - openSUSE Ruby - openSUSE Mailing Lists

[opensuse-ruby] Revised gem packaging
by Stephan Kulow 18 Dec '12

18 Dec '12

Hi, Want to know what I did for #hackweek8? I pulled ruby packaging apart and put it back together. I... - split ruby-common from the ruby package, so it can also be used from ruby 1.8 distros - added patched rpms to devel:languages:ruby:backports for older distros to support overwriting macros and ruby dependencies (11.4 and sle11) - enhanced the %gem_install macro - wrote a gemspec to rpm converter to have requires and provides in rpm automatic without gem2rpm run - changed the gem2rpm template heavily The key idea behind my work was that creating gem.rpm with gem2rpm is easy, updating is problematic (and over half the gems in dlre being outdated kind of proves my point :) So the new template has no requires and no provides, because rpm can find out both from the installed .gemspec. E.g. I found a couple of cases that left broken provides with an update (e.g. 0.8.X providing _0_7). But this strange suffixing is no longer necessary anyway. E.g. rails-3_2 has these automatic requires now: ruby(abi) = 1.9.1 rubygem(1.9.1:actionmailer) = 3.2.7 rubygem(1.9.1:actionpack) = 3.2.7 rubygem(1.9.1:activerecord) = 3.2.7 rubygem(1.9.1:activeresource) = 3.2.7 rubygem(1.9.1:activesupport) = 3.2.7 rubygem(1.9.1:bundler) >= 1.0 rubygem(1.9.1:bundler) < 2 rubygem(1.9.1:railties) = 3.2.7 No more bundler-1_0, but a simple bundler < 2. The automatic provides cover the old names, but I kind of hope we can drop them in the future: rubygem(1.9.1:rails) = 3.2.7 rubygem(rails) = 3.2.7 rubygem-rails = 3.2.7 rubygem-rails-3 = 3.2.7 rubygem-rails-3_2 = 3.2.7 rubygem-rails-3_2_7 = 3.2.7 I do not generate buildrequires in the template either, even though this is a rather tough call. We need buildrequires mainly to check that the dependencies are in the repo, but they create several problems: - gems build in "rings" and require a finished -> succeeded step for every ring, a rails update are 4 such rings. YOU GET CRAZY if the obs is busy! - you can't rely on automatism as the gem specificies "rails > 1.0", but there are 4 such rails versions and the build service wants to know which one you mean. And in case the rails version requires a rack > 1.1, it wants to know which one of those. YOU GET CRAZY! As gem packaging has to be 99% automatic to compete with out of rpm gem, I went for calling gem install with -f and ignore buildignores. To have a way to check dependencies in OBS, I created a small package called "all-good", that itself buildrequires all gems in the repository. That means for a rails update you will only need one ring: update all gems and then let the scheduler calculate if all-good can be expanded or if something misses dependencies. (all-good has a script to update the buildrequires if you had new gems) As some gems require specific but old versions of other gems, I created (DISCLAIMER: careful, do not read further if you're easy to upset) a package containing all those gems. This package will build rpms for all gems in the source directory. While fixing the current dependencies, I found 33 gems that I didn't feel worthy enough for their own spec file, so they ended up in d:l:r:e/all-the-others. It should be noted, that all the gems in there are of course tabu for factory submission. If you need a dependency in factory, create a spec file and dig out the license, gems are pretty bad in specifying the license in .gemspec, so most gem2rpm generated spec files have the CHECK(Ruby) license (even though most I found in practice have MIT). As digging out the license is pretty boring work you don't want to do another time when updating the package, I changed gem2rpm to take the license from the output file in case there is no license in the gemspec. This makes it possible to update to a newer version for gems pretty easy: gem2rpm *.gem -o *.spec. Whenever a spec file needs manual adaption, I add a MANUAL comment in there, so you spot in a diff very easy that you need to check e.g. an extra buildrequire or some file list manipulation. If the week had more days, I think I would put the whole %package and %files sections in a macro, so that we can (later) have ruby20 and ruby19 in parallel. If the requires are automatic and the buildrequires nonexistant, it's basically about the %files sections. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

7 78

[opensuse-ruby] gems on SP2
by Bernhard M. Wiedemann 30 Nov '12

30 Nov '12

Hi, I found that when installing https://build.opensuse.org/package/show?package=rubygem-net-ssh&project=dev… on SLE-11-SP2 it does not pull in the rubygems package as a dependency and thus fails to work. I guess the easy fix is to add to the dependency-generator-output: %if 0%{?suse_version} && 0%{?suse_version} < 1130 Requires: rubygems %endif Ciao Bernhard M. -- (o_ //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

4 4

[opensuse-ruby] non-rubyabi-specific gem version dependencies
by Adam Spiers 30 Nov '12

30 Nov '12

rubygemsdeps.rb as provided by ruby-common-1.0 in d:l:r automatically generates Provides: headers which, with one exception, contain the rubyabi version: # version without ruby version - asking for trouble puts "rubygem(#{spec.name}) = #{spec.version}" if rubyabi puts "rubygem(#{rubyabi}:#{spec.name}) = #{spec.version}" puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}) = #{spec.version}" if versions.length > 1 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}) = #{spec.version}" if versions.length > 2 puts "rubygem(#{rubyabi}:#{spec.name}:#{versions[0]}.#{versions[1]}.#{versions[2]}) = #{spec.version}" if versions.length > 3 end For example: rubygem(oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid) = 0.3.2 rubygem(1.9.1:oa-openid:0) = 0.3.2 rubygem(1.9.1:oa-openid:0.3) = 0.3.2 However I have just encountered a situation where I think it would make sense if it also Provided: rubygem(oa-openid) = 0.3.2 rubygem(oa-openid:0) = 0.3.2 rubygem(oa-openid:0.3) = 0.3.2 The "asking for trouble" comment above cryptically suggests that this is a bad idea, but I would like to know why. The situation I have is as follows: - d:l:r:e provides both rubygem-erubis-2_6 and rubygem-erubis-2_7 - systemsmanagement:chef/rubygem-chef requires erubis >= 0 - systemsmanagement:chef/rubygem-chef which requires rubygem-chef is in 'unresolvable' state because the Build Service doesn't know how to choose between the two erubis versions. The clean solution would be to add a hint to rubygem-chef.spec: Requires: rubygem(%{rb_ver}:erubis:2.7) but 'osc build' gets confused by %{rb_ver}. I don't want to manually specify the Ruby version in the .spec file, because there is no specific dependency on Ruby 1.9 and I want the .spec file to build against 1.8 too (e.g. if we linkpac to another project which builds against Ruby 1.8 on SLES11). Another possibility for the hint is Requires: rubygem-erubis >= 2.7 but it would be better if it was possible to use the pessimistic ~> version since that is less likely to break in the future: Requires: rubygem(erubis:2.7) So can someone please explain why having extra automatic Provides: which omit the rubyabi would be asking for trouble? Thanks! Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

3 8

[opensuse-ruby] Re: [opensuse-packaging] openSUSE Packaging Guidelines Update
by Adam Spiers 21 Nov '12

21 Nov '12

Hi again, Adam Spiers (aspiers(a)suse.com) wrote: > Andreas Jaeger (aj(a)suse.com) wrote: > > On Wednesday, November 07, 2012 11:53:50 Adam Spiers wrote: > > > I'm quite new to most of this, but I just wanted to mention / confess > > > that in the last few days I have been attempting to improve > > > > > > http://en.opensuse.org/openSUSE:Packaging_Ruby > > > > Great! > > > > > based on discussions on opensuse-ruby. There are still some > > > unanswered questions which hopefully will be resolved very shortly. > > > > Could you introduce the change on this mailing list as well and ask for > > additional feedback, please? > > I did already ask some people for feedback, but sure - here's an > official "public" request :) These are my current changes: > > http://en.opensuse.org/index.php?title=openSUSE%3APackaging_Ruby&action=his… > > Hopefully they're self-explanatory. > > There are still other things I want to document, but they are blocked > on the outcome of various discussions including an active thread on > opensuse-ruby, e.g. > > http://lists.opensuse.org/opensuse-ruby/2012-11/msg00039.html I have done some more substantial updates to http://en.opensuse.org/openSUSE:Packaging_Ruby IMHO it is now a lot closer to being complete and up to date, but I would welcome reviewers. I have not made any changes to existing policy (in fact that would be difficult anyway, because there wasn't really much hard policy existing before) but have instead tried to explicitly document things which have been mentioned in mailing list discussions and also include some helpful tips for issues which packagers are likely to encounter. Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 0

[opensuse-ruby] build devel:languages:ruby for Tumbleweed?
by Adam Spiers 21 Nov '12

21 Nov '12

Many packages in systemsmanagement:chef are failing to build on openSUSE_Tumbleweed since they can't resolve ruby-macros. https://build.opensuse.org/project/monitor?project=systemsmanagement%3Achef ruby-macros is provided by ruby-common in devel:languages:ruby, but that project is not currently configured to build for openSUSE_Tumbleweed. Would it make sense to enable that? -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 0

[opensuse-ruby] .gitignore in gems
by Adam Spiers 06 Nov '12

06 Nov '12

I noticed that the rubygem-rainbows gem contains three .gitignore files, which cause rpmlint warnings. I'm guessing there are other gems out there with the same problem. Would it make sense to fix this by adding something like find $RPM_BUILD_ROOT -name .gitignore | xargs -n rm to /usr/lib/rpm/gem_install_wrapper.sh? The danger is that there might be an occasion where there was a real need for a gem rpm to include a .gitignore file. The alternatives are: - try to get the upstream gem fixed, or - do the same .gitignore removal in each .spec file, which is annoying and potentially repetitive. -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

3 7

[opensuse-ruby] issues with old rpmlint-mini
by Adam Spiers 05 Nov '12

05 Nov '12

[cross-posted, but let's divide follow-ups: general rpmlint discussion to opensuse-buildservice, and rubygem rpmlint issues to opensuse-ruby, thanks :-] Hi all, It seems that the newest version of rpmlint-mini in OBS is only 1.3. Presumably this means we are lagging quite far behind upstream rpmlint, because 1.4 was released almost a year ago: http://www.zarb.org/pipermail/rpmlint-discuss/2011-December/001008.html One issue with 1.3 (and in fact even 1.4) is that we are getting a bunch of spurious warnings from every rubygem package build, due to ri documentation files containing percent-encoded characters: http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/569 The fix is simple: http://sourceforge.net/p/rpmlint/code/ci/ae8a019e53784a45c59f23a7b09ad47ea7… and could presumably be backported very easily. So what's the policy on updating rpmlint-mini? Thanks, Adam -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-ruby+owner(a)opensuse.org

1 0