> I found the difference of the behavior between Upstream Ruby and Fedora Ruby. > Case 2-1. does not install ri document by "gem install".
When I tested some things for current private-ruby-2.5 branch, the result is okay like this. 2-1. Fedora Ruby by root user ``` <mock-chroot> sh-4.4# gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed ``` 2-2. Fedora Ruby by regular user ``` [mockbuild@23d5fd90050e4ad382984b434162aa67 ~]$ gem install webrick Fetching: webrick-1.4.1.gem (100%) Successfully installed webrick-1.4.1 Parsing documentation for webrick-1.4.1 Installing ri documentation for webrick-1.4.1 Done installing documentation for webrick after 0 seconds 1 gem installed ``` On Tue, Dec 19, 2017 at 7:24 PM, Jun Aruga <[email protected]> wrote: > One more thing. > > You would find format errors for your modification part if you run `rubocop`. > > ``` > $ rubocop operating_system.rb > ``` > > Jun > > > On Tue, Dec 19, 2017 at 7:19 PM, Jun Aruga <[email protected]> wrote: >> Vit thanks for the working. >> >> I tested it. >> >>> 1) If "gem install" as a regular user still works the same. >> >> >> Right now there is a 2 type of packages. >> Some gem package are "default", others are not. >> The gem package that is managed the ruby sub package is not "default" >> like "bigdecimal" >> >> What is the future plan for these kind of pacakge such as "bigdecimal"? >> 1. These are "default" removing the sub package? >> Or 2. Current default package like "cmath" becomes not "default" >> creating the sub package? >> >> >> Fedora Ruby by regular user. >> >> >> ``` >> [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep default >> cmath (default: 1.0.0) >> csv (default: 1.0.0) >> date (default: 1.0.0) >> dbm (default: 1.0.0) >> digest (default: 0.1.0) >> etc (default: 1.0.0) >> fcntl (default: 1.0.0) >> fiddle (default: 1.0.0) >> fileutils (default: 1.0.1) >> gdbm (default: 2.0.0) >> ipaddr (default: 1.2.0) >> scanf (default: 1.0.0) >> sdbm (default: 1.0.0) >> stringio (default: 0.0.1) >> strscan (default: 0.0.1) >> webrick (default: 1.4.0.beta1) >> zlib (default: 1.0.0) >> >> [mockbuild@026f2c75e4664cfe887005e710a5497e ~]$ gem list | grep -v default >> bigdecimal (1.3.3) >> did_you_mean (1.1.2) >> io-console (0.4.6) >> json (2.1.0) >> minitest (5.10.3) >> net-telnet (0.1.1) >> openssl (2.1.0.beta2) >> power_assert (1.1.1) >> psych (3.0.0) >> rake (12.3.0) >> rdoc (6.0.0) >> test-unit (3.2.7) >> xmlrpc (0.3.0) >> ``` >> >> On upstream Ruby >> >> ``` >> $ dest/bin/gem list >> >> *** LOCAL GEMS *** >> >> bigdecimal (default: 1.3.3) >> bundler (default: 1.16.1.pre1) >> cmath (default: 1.0.0) >> csv (default: 1.0.0) >> date (default: 1.0.0) >> dbm (default: 1.0.0) >> digest (default: 0.1.0) >> etc (default: 1.0.0) >> fcntl (default: 1.0.0) >> fileutils (default: 1.0.1) >> gdbm (default: 2.0.0) >> io-console (default: 0.4.6) >> ipaddr (default: 1.2.0) >> json (default: 2.1.0) >> openssl (default: 2.1.0) >> psych (default: 3.0.0) >> rdoc (default: 6.0.0) >> scanf (default: 1.0.0) >> sdbm (default: 1.0.0) >> stringio (default: 0.0.1) >> strscan (default: 0.0.1) >> webrick (default: 1.4.0.beta1) >> zlib (default: 1.0.0) >> ``` >> >>> 2) If "gem install" as root still works the same. >> >> "gem list" result is same for regular user's situation. >> >> I found the difference of the behavior between Upstream Ruby and Fedora Ruby. >> Case 2-1. does not install ri document by "gem install". >> >> 1-1. Upstream Ruby by root user >> >> [root@unused-4-164 ~]# /usr/local/ruby-2.5.0.pre1/bin/gem install digest >> Fetching: digest-0.0.1.gem (100%) >> Successfully installed digest-0.0.1 >> Parsing documentation for digest-0.0.1 >> Installing ri documentation for digest-0.0.1 >> Done installing documentation for digest after 0 seconds >> 1 gem installed >> >> 2-1. Fedora Ruby by root user >> >> <mock-chroot> sh-4.4# gem install webrick >> Fetching: webrick-1.4.1.gem (100%) >> Successfully installed webrick-1.4.1 >> 1 gem installed >> >> 2-2. Fedora Ruby by regular user >> >> [mockbuild@c187f3581b4e45ecb2837fe5ab6a0af5 ~]$ gem install webrick >> Fetching: webrick-1.4.1.gem (100%) >> WARNING: You don't have /builddir/bin in your PATH, >> gem executables will not run. >> Successfully installed webrick-1.4.1 >> Parsing documentation for webrick-1.4.1 >> Installing ri documentation for webrick-1.4.1 >> Done installing documentation for webrick after 0 seconds >> 1 gem installed >> >> >> I do not know this difference is this Fedora Ruby specific. >> This might be related to this issue? >> https://src.fedoraproject.org/rpms/ruby/pull-request/9 >> >>> 3) If the RPM packages in Fedora (probably just noarch) still installs >> and runs just fine. >>> 4) If rubygem- RPM packages build using this ruby are still build and >> >> I could not test below cases. I tried to build rubygem-bundler for >> your Ruby RPMs. >> But I could not build because of conflict with ruby-2.4.2. >> >> rubygem-bundler >> >> ``` >> $ mock -r fedora-rawhide-x86_64 --with tests -n *.rpm >> ... >> Error: >> Problem: cannot install both ruby-libs-2.4.2-85.fc28.x86_64 and >> ruby-libs-2.5.0-0.1.r61214.fc28.x86_64 >> ``` >> >> >> Jun >> >> On Tue, Dec 19, 2017 at 4:12 PM, Vít Ondruch <[email protected]> wrote: >>> >>> >>> Dne 14.12.2017 v 19:03 Vít Ondruch napsal(a): >>>> >>>> Dne 14.12.2017 v 18:41 Vít Ondruch napsal(a): >>>>> Dne 14.12.2017 v 18:23 Jun Aruga napsal(a): >>>>>> OK thanks for the info. >>>>>> >>>>>> Comparing the result of "gem list" command between upstream and our >>>>>> Fedora package, I found the difference. >>>>>> That can be confusing people. >>>>>> >>>>>> Some of the gem are not shown in the result such as cmath for Fedora >>>>>> package ruby. >>>>>> >>>>>> When running below command on mock, we can load cmath that is not in >>>>>> "gem list" on mock, maybe those are only shown as a result of "gem >>>>>> list". >>>>>> >>>>>> ``` >>>>>> irb(main):003:0> require 'cmath' >>>>>> => true >>>>>> ``` >>>>>> >>>>>> Is it possible to add those gems in the result as a compatibility for >>>>>> upstream Ruby? >>>>>> Hidden gems such as cmath are confusing users. >>>>> Interesting. That is definitely unintentional. Will take a look into it. >>>>> >>>> This appears to be related to the default location of where the gems are >>>> installed. Upstream Ruby installs the gems into their directory, we >>>> install the gems into home directory. And therefore RubyGems on Fedora >>>> are trying to load the specifications for the default gems from the home >>>> directory "/builddir/.gem/ruby/specifications/default" (testing in >>>> mock). So far, we never had the default gem specifications, so this was >>>> not issue. >>>> >>>> >>> >>> >>> Here is updated build, which should fix the issues: >>> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=23793602 >>> >>> The patch used to fix this in attachment. I'd love some feedback prior I >>> push this into git. Mainly, I'd like you to test: >>> >>> 1) If "gem install" as a regular user still works the same. >>> 2) If "gem install" as root still works the same. >>> 3) If the RPM packages in Fedora (probably just noarch) still installs >>> and runs just fine. >>> 4) If rubygem- RPM packages build using this ruby are still build and >>> installed correctly. >>> 5) Any additional scenario you can think of ... >>> >>> Thx for testing. >>> >>> >>> Vít >>> >>> _______________________________________________ >>> ruby-sig mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> >> >> >> -- >> Jun Aruga [email protected] >> IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, >> Czech Republic > > > > -- > Jun Aruga [email protected] > IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, > Czech Republic -- Jun Aruga [email protected] IRC: jaruga, Office: TPB(Technology Park Brno) Building C 1F, Brno, Czech Republic _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected]
