virtual/rubygems abuses versions and slots in a way which makes no sense as a hack to get Portage to do what it wants. What problem are you trying to solve, and what needs to be added to the next EAPI to implement this properly?
Actually what we do in virtual/rubygems makes sense to me: we have multiple independent versions that we can install and for this we use slots. I agree that this would not make sense for a normal packages with upstream versioned releases, but I don't see the problem with a virtual. The problem we are trying to solve here is that if we used no slots and only revisions or versions, then it would be much more of a pain to manage stabilization and adding of new ruby providers, because each change would introduce new versions. With the current solution we can simple manage one slot per RUBY_TARGET. Since I don't see a problem to be fixed here I don't need anything in a future EAPI for this.
You are using versions for something that has nothing to do with versioning, and slots for something that has nothing to do with slotting. The versions 1, 2, 3, 4, 5 are not representing actual versions of anything, and it's not the case that version 4 is "better" than version 2.
(In reply to comment #1) > Since I don't see a problem to be fixed here I don't need anything in a > future EAPI for this. I think the "obvious" way to handle this virtual would be to have one version containing something like IUSE="ruby_targets_ruby18 [...] ruby_targets_rbx" RDEPEND=" ruby_targets_ruby18? ( dev-ruby/rubygems[ruby_targets_ruby18] ) [...] ruby_targets_rbx? ( dev-lang/rubinius )" Perhaps the reason for not doing it like that is because that would require the user to manually fiddle with RUBY_TARGETS for the virtual, as well as for rubygems itself? That sounds like something that might be improvable in a new EAPI - there are other virtuals that already use USE flags in this way, such as ffmpeg, and the need to keep the virtual's flags matching the real package does cause user confusion sometimes. In the meantime, if you really want to keep the Ruby-specific workaround, it would work better if, for each version, the RUBY_TARGETS values that that version doesn't cover were package.use.masked. Since USE_EXPAND things aren't required to be in IUSE, if RUBY_TARGETS="ruby18" is enabled globally then the ruby 1.9 version can still match a dep for virtual/rubygems[ruby_targets_ruby18], which obviously isn't intended. (Also, the Rubinius versions are missing package.use.force entries, too.)
I believe it's quite invalid to force a specific version of package through enforcing USE dependencies. It's at least very unkind of you to force package manager to go through all versions of the package looking for one having the use flag you are forcing... I'm not sure if PM is even obligated to look at the older ebuilds when the newest (unmasked) one doesn't have the requested IUSE.
Is there a workaround so that: cave resolve installed-packages -c I encountered the following errors: ! virtual/rubygems Reasons: dev-ruby/bouncy-castle-java-1.5.0147:0::installed, dev-ruby/jruby-openssl-0.7.7:0::installed, dev-ruby/json-1.8.0:0::installed, 2 more Unsuitable candidates: * virtual/rubygems-6:ruby20::gentoo Did not meet virtual/rubygems[ruby_targets_jruby], use existing if possible, installing to / from dev-ruby/rdoc-4.0.1-r1:0::installed (and 2 more) Flag 'ruby_targets_jruby' enabled Did not meet virtual/rubygems[ruby_targets_ruby18], use existing if possible, installing to / from dev-ruby/rdoc-4.0.1-r1:0::installed (and 2 more) Flag 'ruby_targets_ruby18' enabled Did not meet virtual/rubygems[ruby_targets_ruby19], use existing if possible, installing to / from dev-ruby/rdoc-4.0.1-r1:0::installed (and 2 more) Flag 'ruby_targets_ruby19' enabled doesn't end in an error. There has to be something better than --ignore-unable-decisions.
What would be the problem with just using slots in the rubygems ebuild and not using the ruby_target variable? As far as I understand the situation (I mean the way it was meant, not the way it works right now), slots should be used to select specific versions/variants of a package, and RUBY_TARGETS should be used for packages that can install for different ruby versions. So there should either be a single ebuild with RUBY_TARGETS, or ebuilds with slots but without RUBY_TARGETS. Did I misunderstand the concepts here?
I second Simons argument. The current scheme of dependencies breaks paludis/cave by depending on multiple ruby_targets_ useflags for multiple ruby versions. If you have more than one ruby-version in in ruby_targets_ then in tries to find a version of virtual/rubygems that has *all* these flags enabled. This is plain wrong usage of use-flags.
yeah, this is a blocking issue for ruby systems, possible solutions: 1. remove the RUBY_TARGETS from virtual/rubygems, left slots only. 2. remove the ruby_targets depends from the ruby_fakegem eclass, use slots instead get someone fix it? this is a not so cool bug
Gah! Please address this! As it is, I have to jump through hoops to get through paludis/cave. Always with these virtual/rubygems blockers. Or please tell me an efficient workaround to get it to work the way y'all intend it to work? Please? This is an ongoing issue!
This isn't a Paludis issue... You're relying upon the package mangler not producing a correct dependency resolution. This only "works" because of a Portage bug.
Created attachment 377014 [details] virtual/rubygems without slots
OK I generally do not write "me too" comments in bugzilla entries, but firstly I'm really bitten by it, secondly this issue is getting really old now and finally the fact that the title has just been changed by Alex Legler to "does not work with paludis" makes me feel like there is some kind of will to not fix this bug because it is only encountered by paludis users. It is not my will to start a flame but, as a paludis user, I would highly appreciate a clear statement at this point. Is the ruby team considering this a bug and are they going to fix it ? And if so, has the work on this been started ?
I'm voting for this too as if it breaks a PM that adheres to the PMS, the package is broken, not the package manager. As a sidenote, does anyone know if this package works properly with pkgcore?
I committed a change to the dev-lang/ruby and virtual/rubygems ebuilds yesterday that should help with this. The dev-lang/ruby ebuilds now depend on the correct virtual/rubygems slot rather than on dev-ruby/rubygems directly. With this change there is now an explicit dependency on the correct slot of virtual/rubygems which was not there before. I haven't tested this yet on paludis, feedback welcome. I didn't do revbumps for this change since it is my understanding that this is only an issue on new installs.
It's still broken. For the reasons specified in the comments #2 and #7. The whole concept is just broken...
To fix this issue, you would have to provide -one- version of virtual/rubygems that satisfies all use-dependencies. Software does not make use of multiple versions of dependencies for different features. The new dependencies of virtual/rubygems are ok, but this does not resolves the same issue on the dependencies of packages that make use of ruby-fakegem.eclass to virtual/rubygems.
I solved all my problems by adding this ebuild to my overlay. This bug got even more annoying now that ruby2.0 is stable, but the following ebuild makes everything build cleanly now. Feel free to do whatever you want with it. ==== > grep ^[^#] virtual/rubygems/rubygems-7.2.ebuild | cat EAPI=5 USE_RUBY="jruby rbx ruby19 ruby20 ruby21" inherit ruby-ng DESCRIPTION="Virtual ebuild for rubygems" HOMEPAGE="" SRC_URI="" LICENSE="" SLOT="0" KEYWORDS="amd64" IUSE="" pkg_setup() { :; } src_unpack() { :; } src_prepare() { :; } src_compile() { :; } src_install() { :; } pkg_preinst() { :; } pkg_postinst() { :; }
To update on this, the slot dependency "fixed" it for dev-lang/ruby. Everything in dev-ruby/* still breaks. ! virtual/rubygems Reasons: dev-ruby/bundler-1.7.3:0::gentoo Unsuitable candidates: * virtual/rubygems-7:ruby21::gentoo Did not meet virtual/rubygems[ruby_targets_ruby19], use existing if possible, installing to / from dev-ruby/bundler-1.7.3:0::gentoo Flag 'ruby_targets_ruby19' enabled A solution working for me can be found in comment #11. Is there any serious issue with it apart from not supporting keywords on the same level?
Slots are used for packages, that could be installed in multiple versions. As software does not make use of multiple versions of the same package, to satisify all feature-dependencies, the way slots and RUBY_TARGETS are used here is totaly broken. For example: Some video encoding package needs ffmpeg with specific codecs installed. This software will only link to _one_ version of ffmpeg, so there must be one slot with all useflags.
*** Bug 533840 has been marked as a duplicate of this bug. ***
see also http://paludis.exherbo.org/trac/ticket/1319 since we have only workarounds at this point, which is the best/prefered one?
(In reply to cmuelle8 from comment #21) > see also http://paludis.exherbo.org/trac/ticket/1319 > > since we have only workarounds at this point, which is the best/prefered one? start an overlay, fix the ruby eclasses and fork all ruby packages
<QA hat> Guys, we need some reaction here! Variant 'i do not have problems using portage' is NOT an option here. And, as already said - it's not paludis bug, it's misusage of USE expansion. Single stable ebuild with proper USE-flag dependencies will fit perfectly. After introducing new Ruby into portage - introduce new ebuild with new USE-flag dependency. I definitely see no problem here, former python virtual for argparse, for example did the same job perfectly without blowing onto several slots </QA hat>
To make this bug more explicit, this issue is present in several ruby virtuals: virtual/rubygems virtual/ruby-rdoc virtual/ruby-ssl virtual/ruby-threads
Status update: virtual/rubygems : updated virtual/ruby-rdoc : masked for removal virtual/ruby-ssl : updated virtual/ruby-threads : updated, and will soon be masked for removal I'll leave this bug open until the old virtuals are removed.
All the old virtuals are now masked for removal.
