Hi, I was setting up a new system using ~amd64. I wonder that when installing genkernel, which will install sys-fs/lvm2, that I need to specify RUBY_TARGETS: # emerge -pt sys-kernel/genkernel These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] sys-kernel/genkernel-3.4.47 USE="crypt cryptsetup (-ibm) (-selinux)" [nomerge ] sys-fs/cryptsetup-1.6.1 USE="gcrypt nls -kernel -nettle -openssl -python -reencrypt (-selinux) -static -static-libs -udev -urandom" PYTHON_SINGLE_TARGET="python2_7 -python2_5 -python2_6" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" [nomerge ] sys-fs/lvm2-2.02.98 USE="lvm1 readline thin udev -clvm -cman (-selinux) -static -static-libs" [nomerge ] sys-block/thin-provisioning-tools-0.2.1 [nomerge ] dev-lang/ruby-2.0.0_p247:2.0 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" [ebuild N ] dev-ruby/rdoc-4.0.1-r1 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" 457 kB [ebuild N ] dev-ruby/racc-1.4.9 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" 107 kB [ebuild N ] dev-ruby/json-1.8.0 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" 146 kB [ebuild N ] dev-ruby/rake-0.9.6 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" 121 kB [ebuild N ] virtual/rubygems-1:ruby18 RUBY_TARGETS="(ruby18)" 0 kB [ebuild N ] virtual/rubygems-4:ruby19 RUBY_TARGETS="(ruby19)" 0 kB [ebuild N ] virtual/rubygems-6:ruby20 RUBY_TARGETS="(ruby20)" 0 kB [ebuild N ] dev-ruby/rubygems-2.0.3 USE="-server {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" 327 kB [ebuild N ] dev-lang/ruby-1.9.3_p448:1.9 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" 9,819 kB [ebuild N ] sys-kernel/genkernel-3.4.47 USE="crypt cryptsetup (-ibm) (-selinux)" 8,662 kB [ebuild N ] sys-fs/cryptsetup-1.6.1 USE="gcrypt nls -kernel -nettle -openssl -python -reencrypt (-selinux) -static -static-libs -udev -urandom" PYTHON_SINGLE_TARGET="python2_7 -python2_5 -python2_6" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" 1,148 kB [ebuild N ] sys-fs/lvm2-2.02.98 USE="lvm1 readline thin udev -clvm -cman (-selinux) -static -static-libs" 1,200 kB [ebuild N ] sys-block/thin-provisioning-tools-0.2.1 134 kB [ebuild N ] dev-lang/ruby-2.0.0_p247:2.0 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" 10,554 kB [ebuild N ] dev-libs/boost-1.53.0:0/1.53 USE="nls threads -debug -doc -icu -mpi -python -static-libs -tools" PYTHON_TARGETS="python2_7 python3_2 -python2_5 -python2_6 -python3_1 -python3_3" 54,459 kB [ebuild N ] dev-util/boost-build-1.53.0 USE="-examples -python {-test}" 0 kB [nomerge ] dev-ruby/racc-1.4.9 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [nomerge ] dev-ruby/rake-0.9.6 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [ebuild N ] dev-lang/ruby-1.8.7_p374:1.8 USE="berkdb gdbm ipv6 ncurses readline ssl -debug -doc -examples -libedit -rubytests -socks5 -threads -tk -xemacs" 4,153 kB [ebuild N ] app-admin/eselect-ruby-20120106 2 kB [nomerge ] dev-ruby/rake-0.9.6 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [nomerge ] dev-lang/ruby-1.9.3_p448:1.9 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" [nomerge ] dev-ruby/rdoc-4.0.1-r1 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [nomerge ] virtual/rubygems-6:ruby20 RUBY_TARGETS="(ruby20)" [nomerge ] dev-lang/ruby-2.0.0_p247:2.0 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" [nomerge ] dev-ruby/json-1.8.0 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [ebuild N ] dev-util/ragel-6.8 USE="-vim-syntax" 1,183 kB [nomerge ] sys-kernel/genkernel-3.4.47 USE="crypt cryptsetup (-ibm) (-selinux)" [ebuild N ] app-arch/cpio-2.11-r1 USE="nls" 995 kB [nomerge ] dev-ruby/racc-1.4.9 USE="-doc {-test}" RUBY_TARGETS="ruby18 ruby19 ruby20 -jruby" [nomerge ] dev-lang/ruby-2.0.0_p247:2.0 USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -tk -xemacs" [ebuild N ] dev-libs/libyaml-0.1.4 USE="-doc -examples -static-libs {-test}" 461 kB Total: 21 packages (21 new), Size of downloads: 93,921 kB The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by dev-lang/ruby-2.0.0_p247[rdoc] # required by dev-ruby/racc-1.4.9[ruby_targets_ruby20] >=dev-ruby/rdoc-4.0.1-r1 ruby_targets_ruby20 # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby20] # required by dev-lang/ruby-1.9.3_p448[rdoc] # required by dev-ruby/rubygems-2.0.3[ruby_targets_ruby19] # required by virtual/rubygems-4 # required by dev-ruby/rake-0.9.6 # required by dev-ruby/json-1.8.0[-test,-doc,ruby_targets_ruby20] # required by dev-lang/ruby-2.0.0_p247 # required by virtual/rubygems-6 >=dev-ruby/racc-1.4.9 ruby_targets_ruby20 # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby20] # required by dev-lang/ruby-1.9.3_p448[rdoc] # required by dev-ruby/racc-1.4.9[ruby_targets_ruby19] >=dev-ruby/json-1.8.0 ruby_targets_ruby20 # required by dev-lang/ruby-2.0.0_p247 # required by dev-ruby/racc-1.4.9[ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby18] # required by dev-lang/ruby-1.9.3_p448[rdoc] # required by dev-ruby/rubygems-2.0.3[ruby_targets_ruby19] # required by virtual/rubygems-4 # required by dev-ruby/json-1.8.0[-test,ruby_targets_ruby19] >=dev-ruby/rake-0.9.6 ruby_targets_ruby20 # required by dev-lang/ruby-2.0.0_p247 # required by dev-ruby/racc-1.4.9[ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby18] # required by dev-lang/ruby-1.9.3_p448[rdoc] # required by dev-ruby/json-1.8.0[ruby_targets_ruby19] >=dev-ruby/rubygems-2.0.3 ruby_targets_ruby20 The reason is sys-fs/lvm2, which has "thin" as default use flag enabled. With "thin", sys-fs/lvm2 depends on sys-block/thin-provisioning-tools. And the latest thin-provisioning-tools-0.2.1 from 14. Jun 2013 introduced a dependency to Ruby (which I cannot understand... yes, there are Ruby scripts for thin provisioning, but to use thin provisioning, you don't need to use them, so you probably don't want Ruby on your servers if you don't use these scripts). So when thin-provisioning-tools really need Ruby, I would vote for dropping thin as default use flag for lvm2 (it is a special feature, which most people don't use, so no reason to pull in Ruby on these systems). Reproducible: Always
Sorry, thin-provisioning-tools-0.2.1 hit tree yesterday (14. Juli 2013, not June).
*** Bug 476980 has been marked as a duplicate of this bug. ***
Rather than changing the ebuild for lvm2 to make USE="thin" no longer a default, I suggested in my report bug 476980 that the ebuild for sys-block/thin-provisioning-tools-0.2.1 be modified to make ruby an optional USE. This seems to me to be a more elegant solution as the ruby scripts aren't used by most users and thin-provisioning-tools has worked fine in the past and seems to be working now without them. In my previously mentioned report, I submitted an ebuild that I used to compile and install it without ruby. In the last couple of days I've tried using the apps that I have installed which require lvm2 and all seem to be working as I expect them to. Regardless of which way the devs here decide to go forward, there is no reason to have to pull in ruby, or in this case multiple ruby interpreters and their dependencies as a default for a basic installation IMHO.
(In reply to Robert Cabrera from comment #3) > In the last couple of days I've tried using the apps that I have > installed which require lvm2 and all seem to be working as I expect > them to. How did you test? What application did you test? Don't get me wrong, but I am very sure you don't use thin-provisioning at all, so your tests are "bogus". To use thin-provisioning, you would need lvm2 with thin useflag *AND* you need thin-provisioning support in your kernel (CONFIG_DM_THIN_PROVISIONING). Then you are able to create a special volume. But you would know that it is special, wouldn't you? => thin-provisioning isn't something normal people do/you will see in everyone's setup. So no reason to enable it per default. Regarding Ruby: thin-provisioning is an C++ application. They just use Ruby for their 'functional tests' (which is implemented in 'cucumber', a Ruby application). The normal tests require google mock framework, which we also don't provide. => So there is *no* reason for thin-provisioning to depend on Ruby at all. :-) But people who actual use thin-provisioning should decide if they want a Ruby dependency. This bug is for lvm2 and lvm2 should definitely not enable "thin" per default. I just noticed because of the new thin-provisioning package but it should have never been enabled per default and this should get corrected in my eyes.
(In reply to Thomas D. from comment #4) > (In reply to Robert Cabrera from comment #3) > > In the last couple of days I've tried using the apps that I have > > installed which require lvm2 and all seem to be working as I expect > > them to. > > How did you test? What application did you test? > > Don't get me wrong, but I am very sure you don't use thin-provisioning at > all, so your tests are "bogus". > > To use thin-provisioning, you would need lvm2 with thin useflag *AND* you > need thin-provisioning support in your kernel (CONFIG_DM_THIN_PROVISIONING). > Then you are able to create a special volume. But you would know that it is > special, wouldn't you? > > => thin-provisioning isn't something normal people do/you will see in > everyone's setup. So no reason to enable it per default. > > > Regarding Ruby: > thin-provisioning is an C++ application. They just use Ruby for their > 'functional tests' (which is implemented in 'cucumber', a Ruby application). > The normal tests require google mock framework, which we also don't provide. > > => So there is *no* reason for thin-provisioning to depend on Ruby at all. > :-) But people who actual use thin-provisioning should decide if they want a > Ruby dependency. > > This bug is for lvm2 and lvm2 should definitely not enable "thin" per > default. I just noticed because of the new thin-provisioning package but it > should have never been enabled per default and this should get corrected in > my eyes. Thank you for the clarification. However your tone and attitude are completely uncalled for. I'm a 50 year old truck driver not a programmer, but I've been using Gentoo as my primary OS since 2003 and Linux since 1997. I've been a long-time Linux advocate and use my limited skills for Gentoo's advancement more than most. I regularly help in the forums and was the one who fixed spock's Kernel frame-buffer splash patch when it stopped functioning after 3.7.x series kernels were introduced. Furthermore I've probably submitted more bug reports in the past year than most have in their lifetime. Now as to how I tested, I compiled the new version of thin-provisioning-tools and used the three apps (grub, parted, and cryptsetup) in my system which require lvm2 for device mapping and saw they worked as they have done in the past. If indeed thin-provisioning is something most would never use, and the ruby scripts even less so, then perhaps both package ebuilds should be modified. Lvm2 should have USE="-thin" by default instead of enabling it, and thin-provisioning-tools should add USE="ruby" with it disabled by default. This seems to be the logical thing to do in light of both thin=provisioning-tools and its ruby scripts not being required by the vast majority of Gentoo users.
I, too, am hoping to see these ebuilds revised so that thin and ruby USE flags are disabled by default. Just seems more of the Gentoo Way (TM) to allow for those of us who don't use something to not have to build and install it.
I also vote as -thin by default. Stable lvm2-2.02.97-r1 pulls unstable thin-provisioning-tools (as there is no stable version for thin-provisioning-tools).
(In reply to Jean-Francis Roy from comment #7) > I also vote as -thin by default. > > Stable lvm2-2.02.97-r1 pulls unstable thin-provisioning-tools (as there is > no stable version for thin-provisioning-tools). That's not true, you must be reading Portage's output wrong -- thin-provisioning-tools is stable, and 2.02.97* doesn't pull in unstable version.
*** Bug 486142 has been marked as a duplicate of this bug. ***
This is no longer problem because thin-provisioning-tools 0.2.8 -r1 doesn't pull in ruby by default anymore
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e31bcf83eb070afb477f68cf9e22387a3f95e592 commit e31bcf83eb070afb477f68cf9e22387a3f95e592 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-01 21:04:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-01 21:04:37 +0000 sys-fs/lvm2: disable LVM and thin by default See https://www.gentoo.org/support/news-items/2022-11-19-lvm2-default-USE-flags.html. Closes: https://bugs.gentoo.org/476908 Closes: https://bugs.gentoo.org/718910 Signed-off-by: Sam James <sam@gentoo.org> sys-fs/lvm2/lvm2-2.03.14-r5.ebuild | 4 ++-- sys-fs/lvm2/lvm2-2.03.17-r1.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
This was a "very bold" move to say the least. It did hit me when my laptop battery drained somewhere between the update and reading that news item. I think i would never have read that news item anyhow ... But after my laptop did not want to come up anymore i kind of had to. Rescue was far from trivial and would i not be a power-user i would now be on another distro. i do use multiple lvms and luks underneath with a dracut based initrd and without USE=lvm _nothing_ worked as expected, i can not tell what was wrong exactly but things have been very wrong for sure i managed to use a grml to mount everything back together, chroot in and install lvm2 with USE=lvm, after which the system luckily came back up as it was I did not read all of what happened here, but the change done is "potentially massive" and "destructive". And i want to bet that others will complain once they have to reboot their "big-uptime" machines facing a change that can not be covered with a simple news item and the assumption that people will read or fully understand that ...
