| Summary: | [bumprequest] dev-ruby/fcgi - FastCGI library for Ruby | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vadim A. Misbakh-Soloviov (mva) <mva> |
| Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | c.burger, ruby |
| Priority: | Normal | Keywords: | EBUILD |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
new Ruby FCGI gem ebuild.
ruby-fcgi-ng-0.1.0.ebuild New version of dev-ruby/fcgi ebuild |
||
Created attachment 335878 [details]
ruby-fcgi-ng-0.1.0.ebuild
Sorry, I forgot to cleanup ebuild when attach it first time. Now it is cleaned one.
Did you actually test all these arches? If the package has compiled bits it won't work on jruby, so why include that and then exclude it again in the configure/compile phase? (In reply to comment #2) > Did you actually test all these arches? > > If the package has compiled bits it won't work on jruby, so why include that > and then exclude it again in the configure/compile phase? 1) I just take arches from dev-ruby/fcgi and move them to ~arches, since this gem is fork of fcgi gem, where almost nothing was changed (I'm a new upstream). Anyway, I agree, that it should be tested before adding that arches in the tree. 2) I tested it on ruby18, ruby19 and ruby18ee on x86, ~x86 and ~amd64 and it works. 3) It needs testing on other arches and other ruby implementations, but main goal — working on ruby19 — is reached. I can confirm that the ebuild is working fine on amd64 in combination with dev-lang/ruby-1.9.3_p194-r1, whereas dev-ruby/fcgi was not. Is it possible for that reason to mask the USE flag ruby_targets_ruby19 for dev-ruby/fcgi with a reference to this bug? On another note: I am using www-apps/redmine and as soon as the dev-ruby/ruby-fcgi-ng ebuild drops into the Portage tree, they could use an improvement in that regard: - fastcgi? ( dev-ruby/fcgi ) + fastcgi? ( || ( dev-ruby/ruby-fcgi-ng dev-ruby/fcgi ) ) or a little bit more complex (ree18 and jruby environments missing in the example): - fastcgi? ( dev-ruby/fcgi ) + ruby_targets_ruby18? ( + fastcgi? ( dev-ruby/fcgi ) + ) + ruby_targets_ruby19? ( + fastcgi? ( dev-ruby/ruby-fcgi-ng ) + ) Should I open new bug report for "www-apps/redmine" with this bug here as a blocker? Other potential candidates are "dev-ruby/rack" and "www-servers/gorg", but I did not look into these. I vote for removing dev-ruby/fcgi and adding dev-ruby/ruby-fcgi-ng instead, since last one is a fork of first one (because of dead upstream and because of now it has gentoo's ruby-ng.eclass friendly name), just with some improvements by me (btw, I plan to release new version soon). So, keeping both packages in the tree will be just unneded duplicating. (I am a new upstream, if any) (In reply to comment #5) > I vote for removing dev-ruby/fcgi and adding dev-ruby/ruby-fcgi-ng instead, > since last one is a fork of first one (because of dead upstream and because > of now it has gentoo's ruby-ng.eclass friendly name), just with some > improvements by me (btw, I plan to release new version soon). > So, keeping both packages in the tree will be just unneded duplicating. I think you should name your package the same as the now-dead upstream version, and just take it over that way. That will make it a lot easier on all code, including code not using Gentoo. I don't understand how something can have a ruby-ng friendly name. Could you explain that? (In reply to comment #7) > I think you should name your package the same as the now-dead upstream > version, and just take it over that way. Unfortunately, it is impossible. I've already tried to do that thing (I even tried to ask about possibility to post new "fcgi" meg version without becoming as upstream. But all, that rumy guys said me — "Create a -ng version and feel free to distribute it as you want". So, I did it. > That will make it a lot easier on > all code, including code not using Gentoo. eeeerm? > I don't understand how something can have a ruby-ng friendly name. Could you > explain that? It was a bad try of joke. Speaking seriously, I mean, that my upstream repository names "ruby-fcgi-ng" (originally, "ruby-fcgi", since I [sometimes] develop fcgi packages not only for ruby), and that way, using that repo with "fcgi-9999" ebuild, that I using to test it will cause RUBY_S="*-*" hacking, which is bad thing itself. And yes, last thing is my-only-issue, but it is just side effect of Ruby Team's advice to create an -ng version (and, I'll repeat, just a joke), but not the reason to prefer new gem instead of old. --- Or, did you mean, that I should name it as "fcgi-ng", but not "ruby-fcgi-ng"? If so — I bet, it is not a probles, since original fcgi gem author forked it (from himself, lol) to "ruby-fcgi" gem name (which has latest codebase, than "fcgi" one, so that why I also called gem "ruby-fcgi-ng"). (In reply to comment #8) > Unfortunately, it is impossible. I've already tried to do that thing (I even > tried to ask about possibility to post new "fcgi" meg version without > becoming as upstream. But all, that rumy guys said me — "Create a -ng > version and feel free to distribute it as you want". So, I did it. Sigh. And I guess the original upstream doesn't respond at all... > > That will make it a lot easier on > > all code, including code not using Gentoo. > eeeerm? If you would just release an fcgi gem then people using plain gems would also be helped without having to know about a new package name. In any case, if that isn't possible, then I'd still prefer that we add this as a new version of dev-ruby/fcgi so that we don't need to deal with the change in all packages, like Christian points out. Unless your version isn't completely compatible. (In reply to comment #9) > change in all packages, like Christian points out. Unless your version isn't > completely compatible. It seems compatible -- at least Redmine 2.2.1, Ruby 1.9.3_p194, Rails 3.2.11 works flawlessly with it. Of course there still could be some issues with other software. I think it is not that relevant, but just to be sure: I used www-servers/lighttpd as a frontend. (In reply to comment #5) > I vote for removing dev-ruby/fcgi and adding dev-ruby/ruby-fcgi-ng instead, In the long run I would agree, but for the short term it might be nice to have a transitional phase, where people can adjust their dependencies in overlays if necessary and test the new ebuild. I see three possible solutions: 1) Two packages "dev-ruby/fcgi" and "dev-ruby/ruby-fcgi-ng" where both packages block each other and the new "dev-ruby/ruby-fcgi-ng" is only a dependency where the old one does not work (for example with ruby 1.9.3). In the long run the old package could be removed, maybe even a package move performed. But a package move might not be the best idea. 2) just add it to the Portage tree as "dev-ruby/fcgi-0.9.0" 3) ideally: take ownership of ruby gem Solution 1) Probably would create a problem, where both packages are required to be installed simultaneously. If ruby_targets_ruby18 and ruby_targets_ruby19 are both enabled (which they are by default) then "dev-ruby/ruby-fcgi-ng" would have to take precedence and then it might break some existing installation. But the problem might be solveable. Solution 2): In that case some fiddeling has to be done with RUBY_FAKEGEM_NAME and RUBY_FAKEGEM_VERSION in the new ebuild. But it is feasible. Solution 3) (In reply to comment #8) > becoming as upstream. But all, that rumy guys said me — "Create a -ng > version and feel free to distribute it as you want". So, I did it. Just to be sure: Did you ask "saks" or "evaryont" per e-mail directly? It looks like "saks" was added by evaryont in 2009 as an owner of "fcgi". If you asked the people behind rubygems.org, I could understand that they refuse to give you ownership of the project. Passing ownership without consent of the previous owner can be a messy business. Why should they be involved? From what I see on rubygems.org, could it not be that "saks" had a fork on his own http://rubygems.org/gems/ruby-fcgi shortly before he was added to "fcgi". Then it seem that the situation is repeating: old upstream got lost, new one appears. "saks" did a commit to GitHub on 8th January this year. So I like to think, that his e-mail address given at https://github.com/saks is still valid. If he did not react to your e-mail "mva", I could try again. Maybe if more people ask him to add you as an owner, he will get annoyed and give in. :) Clearly solution 3) is the cleanest. But if that does/did not work, I would prefer solution 2) (as Hans does) with a litte extra: Could you make a new Rubygem "fcgi-ng" with version 0.9.0? Then you only have to touch RUBY_FAKEGEM_NAME and could publish the ebuild "dev-ruby/fcgi-0.9.0". This seems to me like a relatively clean transition. Still there might be some overall USE flag adjustments required as stated earlier: (In reply to comment #4) > Is it possible for that reason to mask the USE flag ruby_targets_ruby19 for > dev-ruby/fcgi with a reference to this bug? By the way. I've talking with original fcgi gem author now. And, if it'll be okay and he approve me as owner, I'll be possible to release a new version of fcgi gem, as Hans de Graaf suggested. So, wish me luck ;) Heyya! I've got ownership of fcgi gem! So, I'll release 0.9.1 (becuase 0.9.0 was released in another fork) today, in few hours. (In reply to comment #12) > Heyya! > I've got ownership of fcgi gem! > So, I'll release 0.9.1 (becuase 0.9.0 was released in another fork) today, > in few hours. Great! This is really the best outcome for everyone. Thanks for picking this up. Feel free to update the ebuild, it will probably take a bit of time for the ruby people to get to it otherwise. Created attachment 339494 [details]
New version of dev-ruby/fcgi ebuild
Here it is (new ebuild)!
fcgi 0.9.1 is now in the tree. (In reply to comment #15) > fcgi 0.9.1 is now in the tree. Great, it works for me on my amd64 platform in conjunction with Ruby 1.9.3_p392 and lighttpd. Thanks a lot. I've got the following error. # emerge -q dev-ruby/fcgi Verifying ebuild manifests Emerging (1 of 1) dev-ruby/fcgi-0.9.1 from mva Failed to emerge dev-ruby/fcgi-0.9.1, Log file: '/var/tmp/portage/dev-ruby/fcgi-0.9.1/temp/build.log' !!! Fetched file: fcgi-0.9.1.gem VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: MD5 RMD160 SHA1 SHA256 SHA512 WHIRLPOOL * Fetch failed for 'dev-ruby/fcgi-0.9.1', Log file: * '/var/tmp/portage/dev-ruby/fcgi-0.9.1/temp/build.log' looks like ruby gems regenerate gem. Currently I'm very busy, so give me some time to investigate it. (In reply to comment #17) >> Emerging (1 of 1) dev-ruby/fcgi-0.9.1 from mva Uh, stop! it is already in the tree! emerge it from there, please. > emerge -q dev-ruby/fcgi::gentoo Vadim,
> Uh, stop!
> it is already in the tree! emerge it from there, please.
> > emerge -q dev-ruby/fcgi::gentoo
OK! Thanks while you're busy.
Makoto
|
Created attachment 335876 [details] new Ruby FCGI gem ebuild. Hi there! Here is new ruby-fcgi-ng gem, which replaces current dev-ruby/fcgi. Now, it supports ruby18, ruby19, ruby18ee. It also should support jruby and rbx, but I've not tested it yet. It will also support ruby20 when it will be released. gem has new name, since it has new upstream (since old one keep silence for almost 4 years).