I just tried to emerge dev-ruby/rails-1.2.0_rc1, but got the following warning: * checking 209 files for package collisions existing file /usr/bin/rails is not owned by this package existing file /usr/lib64/ruby/gems/1.8/bin/rails is not owned by this package * spent 0.0293121337891 seconds checking for file collisions Which causes the emerge to fail in my case. Perhaps a solution would be to add a suffix for the rails binary? I assume that this version is slotted only because it is a release candidate, and by being slotted people can try it out and still keep their current stable rails version operational, so a proper 1.2.0 release would replace 1.1.6 and the file collisions would not matter. I'm now going to turn off collision-protect. :-)
yuck, I didn't catch this one on my upgrade. I'm thinking about it...
I guess the big question is whether you want to put rails 1.2 also into a SLOT when the official version is released. Even then, it may make sense to just overwrite the rails application so that new projects are created with 1.2, but the 1.1 installation is still available for older projects. Personally my preference would be to NOT put rails 1.2 into a separate SLOT. First of all v1.2 is pretty much compatible with 1.1. So far I've seen no problems running a fairly complex site with 1.2, so it is unlikely that things should stop working. Also, upstream believes that freezing rails into your application directory is the way to go if you want stability. When Rails 1.2 is not slotted then we should just forget about this bug and see it as an inconvenience during testing.
I think getting rid of slotting here makes sense. However, since 1.1 is slotted as 1.1, even if we slot 1.2 as 0, it is still considered a different slot, no? So, I'm not sure how to get around the slotting issue.
I'm not a big expert on SLOTs, but I think you are correct that putting rails into SLOT 0 would be different from SLOT 1.1. One approach would be to just keep things in SLOT 1.1, document the history in the ebuild, and not care about the version mismatch. This could become confusing at some point, but it would be mostly transparent to end users anyway.
Caleb: to move from slotted to non-slotted, use DEPEND="!<dev-ruby/rails-1.2.0_rc1"
As I'm sure all of you who are watching this bug are aware, Rails 1.2 has gone final. (Official?) Announcement here: http://weblog.rubyonrails.org/2007/1/19/rails-1-2-rest-admiration-http-lovefest-and-utf-8-celebrations I wasn't sure if I should have filed this under a new bug or not, so if I actually was, forgive me.
Sal: normally the developer responsible for the package will notice the new version also and bump it in portage. If nothing has happened for say two weeks, then it is fine to open a bug for it.
*** Bug 169095 has been marked as a duplicate of this bug. ***
Adding ruby.
(In reply to comment #5) > Caleb: to move from slotted to non-slotted, use > DEPEND="!<dev-ruby/rails-1.2.0_rc1" That's one way, but of course introduces a blocker. Another way would be to do slotmoves to put everything in SLOT=0. I'm not particularly familar with profile/updates stuff, but I think the entries would look something like: slotmove =dev-ruby/rails-1.1* 1.1 0 slotmove =dev-ruby/rails-1.2* 1.2 0
Another approach would be to leave things slotted. Fix the packages so they install /usr/bin/rails-${SLOT}, then do up an eselect module for setting /usr/bin/rails
Speaking from my own experience it is actually nice to have things slotted, as I have several applications that use either version of Rails, and freezing isn't always a solution. Also some applications (radiant comes to mind) don't include the version of rails in their distribution. Having an eselect module would at least solve the file collision in an elegant way.
Has anyone poked at this?
I did some work on a rails eselect module, but never fully finished it. I think I had something that worked but needed to be finished, packaged and tested. I'll try to dig around this weekend and attach it to the bug so that other people can play with it.
Created attachment 124802 [details] rails.eselect module eselect module for rails
Created attachment 124803 [details] rails-1.2.3.ebuild Updated rails-1.2.3 ebuild which uses eselect. The rails-1.1.6 ebuild should be updated in the same way, and the eselect module should be packaged in an ebuild.
I think the eselect module would have to be a different package. The reason is that if both rails-1.1.x and rails-1.2.x both install an eselect module, you'll still have the file collision,
Reassigning to ruby.
Obviously the eselect modules must be a separate package, I just included it here for easy testing. I've now made an ebuild for the eselect module and updated rails (and capistrano) ebuilds to use them. I'd appreciated some testing and feedback before putting them into the tree. They can be found in my git overlay at http://moving-innovations.com/overlay/
I got this error during the merging of either rails slot: !!! Error: Can't set a new provider /home/nichoj/checkouts/graaff-overlay/dev-ruby/rails/rails-1.1.6-r1.ebuild: line 41: 2154 Killed eselect rails update --if-unset Somehow, it also ended up removing /usr/bin/rails, which was a real file from current rails-1.2.
Since things are symlinked as /usr/bin/rails-${PV}, and it only gets updated during postinst if it's not set, wouldn't it break between version bumps? ie /usr/bin/rails points to rails-1.2.3, and you upgrade to rails-1.2.4 Would it make more sense to install it as /usr/bin/rails-${SLOT}, so it's continue s to work between version bumps?
Addressed in 1.1.6-r2 and 1.2.1-r1.
