nokogiri.gem is missing two source tarballs

[dwayne-mss]

I believe the gem file should include the source tarballs for libiconv-1.14 and zlib-1.2.8

I've recently tried to install nokogiri on a Windows 2012 Server. This node did not have internet access. I could not get it to installed, and tried the versions with the prebuilt DLL's too. Based on the errors in the logs, it seemed to be intent on compiling the libiconv-1.14 and zlib-1.2.8 libraries. I also found that neither of these source bundles were included in the .../ports/archives folder within the nokogiri GEM file, while the source bundles for libxml2-2.9.2 and libxslt-1.1.28 were.

The install process did not log an attempt to download either of the missing source bundles, though I see in some other threads that it logged activity when successfully downloading the bundles. Since my server did not have internet access, it could not download the bundles.

So I unpacked the GEM, added the two source bundles, created a new gemspec from the old GEM, added the two new files, and repackged the GEM. Installing the new GEM worked like a champ (though it did take a while to install).

I was using nokogiri-1.6.7.2, and that is the version that I repackaged. I tried to install nokogiri-1.6.8, but it was also failing, even with the prebuilt DLLs. But I did not examine the GEM file to see if it was also missing the two source bundles.

[flavorjones]

Hi @dwayne-mss,

Thanks for opening this issue after our conversation on nokogiri-talk. I'll try to take a look at it this week.

[dwayne-mss]

Any updates on this?

[flavorjones]

It looks like Nokogiri isn't using the locally packaged tarballs, either. Something dreadfully wrong. Will investigate.

[flavorjones]

Ah, disregard my above comment. The original problem described is still valid, though.

[larskanis]

Yes, we could add libz and libiconv to the source gem, but that would double the size of the source gem. This is because we expect libz and libiconv to be available on the system installation for all operating systems except on Windows. And on Windows the binary gem is installed per default, which has libz and libiconv built in. If the user wishes to install the source gem instead of the binary, gem install triggers a download of the missing tars for libz and libiconv from the internet on Windows. Alternatively the user can install libxml2 and libxslt separately (for instance by chocolaty or cygwin) and use gem inst --use-system-libraries . Given that only 3 percent of the downloads from rubygems are for Windows (x86 or x64), and that the default binary gem should usually work, I wonder if it's worth to double the source gem size. It's only useful in the case that the system is Windows, the binary gem is not suitable, libxml2/libxslt are not available on the system and there's not internet connection. Maybe we should investigate why the binary gem doesn't work? Other opinions?

[flavorjones]

@dwayne-mss The comments about by @larskanis are pretty convincing, and I'd prefer not to include these DLLs for users compiling from source on Windows.

You mention that you had difficulty with the pre-built DLL version as well. Can you share details about that?

We tried to thoroughly document how to successfully install Nokogiri on Windows a few different ways at nokogiri.org. Can you think of anything those documents are missing?

[dwayne-mss]

I agree that producing large gem files for such extreme cases is not a good approach. That said, it seems like the installer should be updated. If the DLLs are not going to be packaged in the GEM, then don’t have the installer look for them. With the release of nokogiri-1.2.8.1, we tried again to use the GEM bundled for Windows with pre-compiled DLLs. What I found might be useful for others. I’m installing on a Windows Server 2012 R2 system. I was sure that would be an x64 platform, so we tried installing the x64 packaged GEM… and it failed with errors. I then ran the ‘gem env’ command and saw that the platform was listed as ‘x86’. Using the x86 based GEM installed quickly and without any issues. I believe this was likely the issue all along for me. Having the correct platform GEM installed in our local gem repo allowed the ‘bundle’ command to find the correct GEM to install vs the generic one without the needed DLLs. I am hopeful the the upgrade to nokogiri-1.7 will go smoothly now that I know how the platform plays into the install process. On Jan 13, 2017, at 8:34 AM, Mike Dalessio <notifications@github.com<mailto:notifications@github.com>> wrote: @dwayne-mss<https://github.com/dwayne-mss> The comments about by @larskanis<https://github.com/larskanis> are pretty convincing, and I'd prefer not to include these DLLs for users compiling from source on Windows. You mention that you had difficulty with the pre-built DLL version as well. Can you share details about that? We tried to thoroughly document how to successfully install Nokogiri on Windows a few different ways at nokogiri.org<http://www.nokogiri.org/tutorials/installing_nokogiri.html#windows>. Can you think of anything those documents are missing? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1506 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ASRYrdqP0lhTIOZLSeB34rYNNXPTe9ghks5rR31WgaJpZM4JIFWq>.

[larskanis]

@dwayne-mss All recent Windows Server versions are for the x64 platform. But you need to install the x86 or x64-gem that matches your installed ruby platform. Good to hear it works for you!