I would like to propose to put ruby-config in package.mask and remove it from the tree after a suitable period. I have the following arguments for that: - we currently only have ruby 1.8.x in the tree, so having ruby-config for just one profile is overkill - ruby-config has a number of open bugs that have not been fixed in quite some time - many Gentoo packages are now using eselect to accomplish the same thing, and in fact we already have an eselect module in the ruby overlay that selects between ruby 1.8.x and ruby 1.9.x, so I expect that in the future we will use eselect rather than extending ruby-config.
I've now dropped the dependency on ruby-config in the dev-lang/ruby-* ebuilds and put ruby-config in package.mask.
Shouldn't revision be bump for such change? That would save some time to find out why the package was masked. Right now my system is crying it's got some missing dependency and I have to manually reinstall ruby to sort it out. just my 2 cents Thanks, Rob
(In reply to comment #2) > Shouldn't revision be bump for such change? That would save some time to find > out why the package was masked. emerge should show you the comment above of the line in package.mask, containing the "why the package was masked". > Right now my system is crying it's got some > missing dependency and I have to manually reinstall ruby to sort it out. The ruby ebuilds have been updated to no longer depend on ruby-config. You might want to sync your tree.
> The ruby ebuilds have been updated to no longer depend on ruby-config. You > might want to sync your tree. > There should be a revision bump so that manual user intervention is not required if possible along with a a note in the mask message along the lines of "Please reinstall ruby and uninstall ruby-config." There is also stuff in the ruby ebuilds in the pkg_postinst and pkg_postrm that mentions and uses ruby-config that is still there as of my sync.
(In reply to comment #4) > > The ruby ebuilds have been updated to no longer depend on ruby-config. You > > might want to sync your tree. > > > > There should be a revision bump so that manual user intervention is not > required Revision bump is required only when the files installed by given package will be changed. It is not the case here.
(In reply to comment #3) > The ruby ebuilds have been updated to no longer depend on ruby-config. You > might want to sync your tree. Portage isn't strict about dependencies (and doesn't check deps for installed packages), so updating portage tree won't make a difference. I'm saying about error like: ... When adding run dependencies as post dependencies: ... When adding PackageDepSpec 'dev-lang/ruby': ... When adding installed package 'dev-lang/ruby-1.8.6_p287-r3:1.8::installed': ... When adding run dependencies as post dependencies: ... When adding PackageDepSpec '>=dev-ruby/ruby-config-0.3.1': ... No visible packages matching '>=dev-ruby/ruby-config-0.3.1', falling back to installed package 'dev-ruby/ruby-config-0.3.2::installed' Which forces user to investigate and reinstall the package. _Personally_ I think there should be a revision bump. Without a revision bump this is messing my system up, as I've got installed package with missing dependency (at least until I reinstall it). That from my point of view qualify as a broken system. (In reply to comment #5) > Revision bump is required only when the files installed by given package will > be changed. It is not the case here. > I do not agree here. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3 under Versioning and revision bumps: "Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade." I don't want to have a broken system and I do want to upgrade. Maybe that makes me minority, I don't know but I like _all_ deps are satisfied (even for installed packages). It's just a bit annoying I need waste my time to investigate why the package was masked in the first place and manually reinstall all packages which depends on it, where it could easily be done automatically in the first place by simple revision bump.
I second Robert's view on the matter.
I've removed the now obsolete pkg_postinst and pkg_postrm functions from the ruby ebuilds. Thanks for noticing. I have also reverted the package.mask entry until we are really ready to remove it. I don't think this warrants a version bump right now so we will do this some time after we've bumped the ruby ebuilds for a real reason. Thanks for reporting the issue.
Now that ruby-config is gone, will the symlink of /usr/bin/ruby18 -> /usr/bin/ruby be handled by something else?
(In reply to comment #9) > Now that ruby-config is gone, will the symlink of /usr/bin/ruby18 -> > /usr/bin/ruby be handled by something else? As Hans said, there is an eselect module for Ruby. It is currently being tested with Ruby 1.9 in the overlay and will likely hit the tree when 1.9.1 is out, which is late January.
Ok, but doesn't this break anything that's looking for a /usr/bin/ruby executable on the system? ruby-postgres, for example, can't build: >>> Emerging (1 of 1) dev-ruby/ruby-postgres-0.7.9.20080128 * postgres-0.7.9.2008.01.28.gem RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... >>> Source unpacked. >>> Compiling source in /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/work ... >>> Source compiled. >>> Test phase [not enabled]: dev-ruby/ruby-postgres-0.7.9.20080128 >>> Install ruby-postgres-0.7.9.20080128 into /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/image/ category dev-ruby /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/temp/environment: line 1416: ruby: command not found install: missing file operand Try `install --help' for more information. /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/temp/environment: line 1440: /usr/bin/ruby: No such file or directory Building native extensions. This could take a while... Successfully installed postgres-0.7.9.2008.01.28 1 gem installed >>> Completed installing ruby-postgres-0.7.9.20080128 into /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/image/ * QA Notice: command not found: * * /var/tmp/portage/dev-ruby/ruby-postgres-0.7.9.20080128/temp/environment: line 1416: ruby: command not found
Just my tuppence, having done a fresh install of ruby this morning on a fresh, shiny, new Gentoo box, and being unable to find /usr/bin/ruby, thinking "hmm ruby-config", seeing ruby-config not installed (and all of that). I see an eselect module is in the overlay, but for the rest of us in the mainstream, shouldn't ruby-config stick around until the eselect module moves into the main tree, as it is the current way of managing the /usr/bin/ruby (and friends) symlinks? Or shouldn't the current ebuilds be updated to do the symlink (/usr/bin/ruby -> /usr/bin/ruby18)?
I've just reverted my ruby-config changes for the ruby ebuilds currently in CVS, since this seems to be the only clean way to resolve this situation. It seems I was a bit too eager to wave goodbye to ruby-config and didn't think the whole upgrade process through until the end. My apologies for breaking things along the way, that obviously wasn't my intention.
Thanks, Hans. I appreciate your work in moving the ebuilds forward. I'm sure a good solution will come along sooner or later.
(In reply to comment #13) > I've just reverted my ruby-config changes for the ruby ebuilds currently in > CVS, since this seems to be the only clean way to resolve this situation. Thanks! I look forward to managing ruby with eselect, and appreciate the reversion in the meantime.
We've added an initial version of ruby and eselect-ruby to the tree yesterday, so please feel free to test it: dev-lang/ruby-1.8.6_p287-r10.
Now that eselect-ruby is stable, I masked ruby-config. # Alex Legler <a3li@gentoo.org> (15 May 2009) # Masked for removal wrt bug #251833. Due for removal in 30 days. # Use app-admin/eselect-ruby instead. dev-ruby/ruby-config =dev-lang/ruby-1.8.6_p114
RIP, ruby-config. Closing.
