| View previous topic :: View next topic |
| Author |
Message |
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
 Posted: Mon Jan 06, 2025 4:20 pm Post subject: [dev-ruby/typeprof] Slot conflict, failed system update. |
 |
|
Hi there,
I have been unable to update my system for several days now due to “typeprof”.
| Code: | !!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
dev-ruby/typeprof:0
(dev-ruby/typeprof-0.30.1:0/0::gentoo, installed) USE="-test" RUBY_TARGETS="ruby32 ruby33 ruby34" pulled in by
>=dev-ruby/typeprof-0.30.1[ruby_targets_ruby34(-)] required by (dev-lang/ruby-3.4.1:3.4/3.4::gentoo, installed) USE="gdbm ssl -berkdb -debug -doc -examples (-jemalloc) -jit -socks5 (-static-libs) -systemtap -tk -valgrind -xemacs"
^^ ^^^^^^
(dev-ruby/typeprof-0.21.11:0/0::gentoo, ebuild scheduled for merge) USE="-test" RUBY_TARGETS="ruby31 ruby32 ruby33" pulled in by
>=dev-ruby/typeprof-0.12.2[ruby_targets_ruby31(-)] required by (dev-lang/ruby-3.1.6-r2:3.1/3.1::gentoo, ebuild scheduled for merge) USE="gdbm ipv6 ssl -berkdb -debug -doc -examples (-jemalloc) -jit -socks5 (-static-libs) -systemtap -tk -valgrind -xemacs" |
I set in "make.conf":
| Code: | | RUBY_TARGETS="ruby32 ruby33 ruby34" |
I set in "/etc/portage/package.use/00Ruby":
| Code: | | */* RUBY_TARGETS: ruby32 ruby33 ruby34" |
I also used "--backtrack=30" with no success. Could someone help me? Thanks. |
|
| Back to top |
|
 |
alamahant
Advocate
Joined: 23 Mar 2019
Posts: 3936
|
| Posted: Mon Jan 06, 2025 4:33 pm Post subject: |
|
|
Try to set
| Code: |
RUBY_TARGETS="-* ruby32 ruby33"
|
in package.use
_________________
Last edited by alamahant on Mon Jan 06, 2025 4:37 pm; edited 1 time in total |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 31411
Location: here
|
| Posted: Mon Jan 06, 2025 4:35 pm Post subject: |
|
|
It looks like you still have ruby 3.1 installed which depends on <dev-ruby/typeprof-0.30.1 so portage can't upgrade to dev-ruby/typeprof-0.30.1.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
| Posted: Mon Jan 06, 2025 6:05 pm Post subject: |
|
|
| alamahant wrote: | Try to set
| Code: |
RUBY_TARGETS="-* ruby32 ruby33"
|
in package.use |
Same issue.
| fedeliallalinea wrote: | | It looks like you still have ruby 3.1 installed which depends on <dev-ruby/typeprof-0.30.1 so portage can't upgrade to dev-ruby/typeprof-0.30.1. |
I have already removed ruby version 3.1 and tried to update my system by selecting all available {eselect} profiles (ruby32 - ruby33 - ruby34); same issue. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Mon Jan 06, 2025 6:11 pm Post subject: |
|
|
| How did you remove ruby:3.1? The output says that it is scheduled to be installed. |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 31411
Location: here
|
| Posted: Mon Jan 06, 2025 7:01 pm Post subject: |
|
|
Please share the full emerge output.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
| Posted: Mon Jan 06, 2025 9:18 pm Post subject: |
|
|
| Hu wrote: | | How did you remove ruby:3.1? The output says that it is scheduled to be installed. |
I remove from @world with:
| Code: | | emerge --deselect ruby |
then:
| Code: | emerge --depclean --ask --verbose =dev-lang/ruby-3.1.6-r2
Calculating dependencies... done!
dev-lang/ruby-3.1.6-r1 pulled in by:
dev-ruby/bundler-2.6.2 requires dev-lang/ruby:3.1
dev-ruby/date-3.4.1 requires dev-lang/ruby:3.1
dev-ruby/did_you_mean-1.6.3 requires dev-lang/ruby:3.1
dev-ruby/did_you_mean-2.0.0 requires dev-lang/ruby:3.1
dev-ruby/io-console-0.8.0 requires dev-lang/ruby:3.1
dev-ruby/irb-1.14.3 requires dev-lang/ruby:3.1
dev-ruby/json-2.9.1 requires dev-lang/ruby:3.1
dev-ruby/kpeg-1.3.3 requires dev-lang/ruby:3.1
dev-ruby/logger-1.6.4 requires dev-lang/ruby:3.1
dev-ruby/minitest-5.25.4 requires dev-lang/ruby:3.1
dev-ruby/net-imap-0.3.7 requires dev-lang/ruby:3.1
dev-ruby/power_assert-2.0.5 requires dev-lang/ruby:3.1
dev-ruby/psych-5.2.2 requires dev-lang/ruby:3.1
dev-ruby/racc-1.8.1 requires dev-lang/ruby:3.1
dev-ruby/rake-13.2.1 requires dev-lang/ruby:3.1
dev-ruby/rbs-3.8.1 requires dev-lang/ruby:3.1
dev-ruby/rdoc-6.10.0 requires dev-lang/ruby:3.1
dev-ruby/reline-0.6.0 requires dev-lang/ruby:3.1
dev-ruby/rexml-3.4.0 requires dev-lang/ruby:3.1
dev-ruby/rss-0.3.1 requires dev-lang/ruby:3.1
dev-ruby/rubygems-3.6.2 requires dev-lang/ruby:3.1
dev-ruby/stringio-3.1.2 requires dev-lang/ruby:3.1
dev-ruby/strscan-3.1.2 requires dev-lang/ruby:3.1
dev-ruby/test-unit-3.6.7 requires dev-lang/ruby:3.1
dev-ruby/typeprof-0.21.11 requires dev-lang/ruby:3.1
virtual/ruby-ssl-15 requires dev-lang/ruby:3.1[ssl], dev-lang/ruby:3.1
virtual/rubygems-21-r1 requires dev-lang/ruby:3.1
>>> No packages selected for removal by depclean |
Unfortunately, I had to force the uninstallation with:
| Code: | | emerge --unmerge -C =dev-lange/ruby-3.1.6-r2 |
|
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Mon Jan 06, 2025 9:38 pm Post subject: |
|
|
| You should not use emerge --unmerge, because that does not check dependency information. You removed ruby:3.1 without removing all the reasons you need it, so Portage is now trying to bring it back. You should have used emerge --ask --depclean to remove ruby:3.1 and all packages that hard-require it. I suspect from your output that these other packages conditionally require it based on RUBY_TARGETS. What is the output of emerge --pretend --verbose virtual/ruby-ssl virtual/rubygems all-installed-packages-in-dev-ruby? |
|
| Back to top |
|
|
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
| Posted: Tue Jan 07, 2025 7:42 pm Post subject: |
|
|
| Hu wrote: | | You should not use emerge --unmerge, because that does not check dependency information. You removed ruby:3.1 without removing all the reasons you need it, so Portage is now trying to bring it back. You should have used emerge --ask --depclean to remove ruby:3.1 and all packages that hard-require it. I suspect from your output that these other packages conditionally require it based on RUBY_TARGETS. What is the output of emerge --pretend --verbose virtual/ruby-ssl virtual/rubygems all-installed-packages-in-dev-ruby? |
I reinstalled ruby:3.1 but I don't understand why by checking the local USE flag (all required packages) 'ruby31' is enabled. Why? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Tue Jan 07, 2025 8:32 pm Post subject: |
|
|
| Assuming your Gentoo Portage tree is relatively current, the answer is that ruby-3.1 is not enabled by the upstream tree. As I read the history, this was changed in profiles/base/make.defaults: drop ruby31 from RUBY_TARGETS in October 2024. Therefore, either your tree is notably out of date or you have a local modification in /etc/portage that is enabling it. What is the output of grep -inr RUBY_TARGETS /etc/portage/make.conf /etc/portage/package.use? |
|
| Back to top |
|
|
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
| Posted: Wed Jan 08, 2025 7:10 pm Post subject: |
|
|
| Hu wrote: | | Assuming your Gentoo Portage tree is relatively current, the answer is that ruby-3.1 is not enabled by the upstream tree. As I read the history, this was changed in profiles/base/make.defaults: drop ruby31 from RUBY_TARGETS in October 2024. Therefore, either your tree is notably out of date or you have a local modification in /etc/portage that is enabling it. What is the output of grep -inr RUBY_TARGETS /etc/portage/make.conf /etc/portage/package.use? |
grep -inr RUBY_TARGETS /etc/portage/make.conf
| Code: | | 16:RUBY_TARGETS="ruby32 ruby33 ruby34" |
grep -inr RUBY_TARGETS /etc/portage/package.use
| Code: | | https://paste.gentoo.zip/GBFuVNcx |
I also tried removing the old ruby implementations but portage would still like to install typeprof version 0.21.11.
https://wiki.gentoo.org/wiki/Ruby#Removing_an_old_implementation
| Code: | | */* RUBY_TARGETS: -ruby31 ruby32 ruby33 ruby34" |
|
|
| Back to top |
|
|
joelparthemore
n00b
Joined: 15 Nov 2014
Posts: 29
|
| Posted: Fri Jan 10, 2025 6:06 pm Post subject: was having the exact same problem, now solved |
|
|
| Reading through this thread, I was able to identify and resolve the problem. It came down to a bunch of autounmask updates to /etc/portage/package.use that made reference to ruby3.1, including one requiring ruby3.1 for typeprof. When I commented out all of the references to ruby3.1 in package.use -- and only when I commented out all of them! -- everything went fine. I suspect ranumm may have the same problem. At some earlier point they were needed; now they're just in the way. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Fri Jan 10, 2025 6:19 pm Post subject: |
|
|
I concur. ranumm's output shows signs of extensive use of autounmask, and confirms that a local setting enables ruby3.1 for typeprof: | Code: | | /etc/portage/package.use/xorg-server:235:>=dev-ruby/typeprof-0.21.2 ruby_targets_ruby31 |
Removing that, and the other stale ruby3.1 entries, should help.
The attempted wildcard is ineffective because it occurs before the specific lines that enable the obsolete ruby targets. Additionally, the wildcard is slightly incorrect. It should not have a trailing quote. |
|
| Back to top |
|
|
leifbk
Guru
Joined: 05 Jan 2004
Posts: 425
Location: Bærum, Norway
|
| Posted: Fri Jan 10, 2025 7:35 pm Post subject: Re: was having the exact same problem, now solved |
|
|
| joelparthemore wrote: | | Reading through this thread, I was able to identify and resolve the problem. It came down to a bunch of autounmask updates to /etc/portage/package.use that made reference to ruby3.1, including one requiring ruby3.1 for typeprof. When I commented out all of the references to ruby3.1 in package.use -- and only when I commented out all of them! -- everything went fine. I suspect ranumm may have the same problem. At some earlier point they were needed; now they're just in the way. |
I can confirm that. I ran into the circular dependencies issue about a week ago, and didn't see a quick fix to it, so I just put the ruby34 in package.mask to be resolved later. After seeing this thread, I took a new look at it, and what do I see:
| Code: | balapapa ~ # grep ruby /etc/portage/package.use
virtual/rubygems ruby_targets_ruby31
virtual/ruby-ssl ruby_targets_ruby31
|
I commented out the two offending lines, took ruby34 out of limbo, and then changed the ruby spec in make.conf to RUBY_TARGETS="ruby32 ruby33 ruby34"
emerge -avuDN @world then built/rebuilt 55 packages, and finally
| Code: | balapapa ~ # emerge -aq --depclean --exclude sys-kernel/gentoo-sources --exclude dev-db/postgresql
dev-lang/ruby: 3.1.6-r2 none 3.2.6-r3 3.3.6-r1 3.4.1
|
got rid of ruby31.
It's not the first time I've been perplexed by stale entries in package.use, and I wish there were a way to auto-check it for outdated package versions.
_________________
Grumpy old man |
|
| Back to top |
|
|
ranumm
n00b
Joined: 16 Aug 2019
Posts: 26
|
| Posted: Sun Jan 12, 2025 6:44 pm Post subject: |
|
|
| joelparthemore wrote: | | Reading through this thread, I was able to identify and resolve the problem. It came down to a bunch of autounmask updates to /etc/portage/package.use that made reference to ruby3.1, including one requiring ruby3.1 for typeprof. When I commented out all of the references to ruby3.1 in package.use -- and only when I commented out all of them! -- everything went fine. I suspect ranumm may have the same problem. At some earlier point they were needed; now they're just in the way. |
I confirm that I had to comment out every reference to ruby:31 in order to upgrade @world and subsequently uninstall it definitively via "emerge --depclean".
| Hu wrote: | | The attempted wildcard is ineffective because it occurs before the specific lines that enable the obsolete ruby targets. Additionally, the wildcard is slightly incorrect. It should not have a trailing quote. |
I followed what is reported here (the guide refers to the removal of the ruby:2x implementation) ignoring the reasons for the wildcard and quote. Can you tell me more? What would be the correct syntax?
Also is the target variable in "package.use" really necessary? Wouldn't “RUBY_TARGETS” in "make.conf" be enough?
_
Huge thanks to joelparthemore and leifbk for their feedback! |
|
| Back to top |
|
|
joelparthemore
n00b
Joined: 15 Nov 2014
Posts: 29
|
| Posted: Sun Jan 12, 2025 6:56 pm Post subject: |
|
|
| Quote: | | I confirm that I had to comment out every reference to ruby:31 in order to upgrade @world and subsequently uninstall it definitively via "emerge --depclean". |
I haven't bothered to uninstall it yet, actually, since it's important to read through the depclean list first and see what it's trying to remove; there are some things it's always wanting to remove (like multiple versions of gcc) that I don't want removed. It doesn't matter though, since nothing is left dependent on it. (Yes, I know; depclean should not be put off too long.)
| Quote: | I followed what is reported here (the guide refers to the removal of the ruby:2x implementation) ignoring the reasons for the wildcard and quote. Can you tell me more? What would be the correct syntax?
Also is the target variable in "package.use" really necessary? Wouldn't “RUBY_TARGETS” in "make.conf" be enough? |
You shouldn't need it either place. It's just one more thing that can create problems for you later. If you're going to have it anywhere though then, yes, only put it in make.conf. (I just realized I had it there; took it out; and with that, ruby33 support is gone... no longer needed.) |
|
| Back to top |
|
|
leifbk
Guru
Joined: 05 Jan 2004
Posts: 425
Location: Bærum, Norway
|
| Posted: Sun Jan 12, 2025 7:08 pm Post subject: |
|
|
| ranumm wrote: | | Also is the target variable in "package.use" really necessary? Wouldn't “RUBY_TARGETS” in "make.conf" be enough? |
Usually it is. I think the references to ruby31 in package.use are old, from the time ruby31 was quite new. Since then, the devs have apparently found better methods to point to specific versions of a program than putting them in package.use where ultimately they become a PITA.
Or maybe it is me who have become smarter. The autounmask feature is not very bright, and rather than give you a hint about updating your make.conf, it gives you a ton of updates to package.use. You should probably never put things like "ruby_targets" in the latter file.
This seems to be part of the secret Gentoo lore that most users have to figure out for themselves.
_________________
Grumpy old man |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22981
|
| Posted: Sun Jan 12, 2025 7:45 pm Post subject: |
|
|
| ranumm wrote: | | Hu wrote: | | The attempted wildcard is ineffective because it occurs before the specific lines that enable the obsolete ruby targets. Additionally, the wildcard is slightly incorrect. It should not have a trailing quote. |
I followed what is reported here (the guide refers to the removal of the ruby:2x implementation) ignoring the reasons for the wildcard and quote. Can you tell me more? What would be the correct syntax? |
The stray quote appears not to trouble Portage's parser, though I still recommend against it, as it looks wrong and might be rejected by a future parser. You are correct that the stray quote is in the Wiki page. As such, I consider the Wiki to be wrong, although apparently harmlessly so.
As regards "ineffective", I meant that you had many entries later on that proceeded to re-enable the obsolete ruby target. Consider: | Code: | # head -n3 package.use
*/* PYTHON_TARGETS: python3_10
dev-python/pyyaml PYTHON_TARGETS: python3_11
# emerge -pvO requests pyyaml
These are the packages that would be merged, in order:
[ebuild R ] dev-python/requests-2.32.3::gentoo USE="(test-rust) -socks5 -test" PYTHON_TARGETS="python3_10* python3_12 (-pypy3) -python3_11 -python3_13" 0 KiB
[ebuild R ] dev-python/pyyaml-6.0.2::gentoo USE="-debug -examples -test" PYTHON_TARGETS="python3_10* python3_11* python3_12 (-pypy3) -python3_13" 0 KiB |
If my wildcard entry worked the way you seemed to expect yours to work, then pyyaml ought not to be using python3_11. However, per this output, the specific line later does enable python3_11. Similarly, you had package-specific entries that explicitly enabled ruby31. | ranumm wrote: | | Also is the target variable in "package.use" really necessary? Wouldn't “RUBY_TARGETS” in "make.conf" be enough? |
make.conf always applies to everything, whereas package.use can be per-package or use a wildcard, as appropriate. This makes it more flexible.
Rampant use of autounmask can set a variety of traps for your future self. I recommend being very sparing and cautious in use of autounmask. |
|
| Back to top |
|
|
|
Portage & Programming
