With Dockerfile like that: FROM fedora:33 RUN dnf install -y /usr/bin/gem ruby-devel gcc RUN dnf install -y openssl-devel RUN dnf install -y gcc-c++ RUN gem install github-pages jekyll || cat /usr/local/lib64/gems/ruby/eventmachine-1.2.7/mkmf.log The podman build ends with failure like: ... gcc: fatal error: cannot read spec file '/usr/lib/rpm/redhat/redhat-hardened-cc1': No such file or directory compilation terminated. checked program was: /* begin */ 1: #include "ruby.h" 2: 3: int main(int argc, char **argv) 4: { 5: return !!argv[argc]; 6: } /* end */ I think that either ruby-devel should require redhat-rpm-config, or the /usr/lib/rpm/redhat/redhat-hardened-cc1 file shouldn't be used.
Hello Pavel, installing a gem does not actually need it (when installing extension-free packages), therefore, at the moment it's not Required (nor Recommended). Additionaly, the gem may as well require other `-devel` packages installed, and it's installation is also up to the developer. More on RubyGems exetnsions here: https://developer.fedoraproject.org/tech/languages/ruby/gems-installation.html In your case, redhat-rpm-config is needed, as same build flags are set as when Ruby was built (hopefully there'll be some development in Ruby 3.X timeline to address these issues). Also discussed here: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 As a sidenote, you could install `jekyll` from Fedora repositories, and therefore you would not need any build depencdencies for it. That said, I'm personally inclined to simply add `Recommend` dependency to `ruby-devel` package to better the experience for users (I hit this issue from time to time as well). @vondruch WDYT?
> In your case, redhat-rpm-config is needed, As long as it is only in my case ... but I expected that the baked-in flags are used in each "binary" build that is done against ruby-devel. > As a sidenote, you could install `jekyll` from Fedora repositories, I initially tried, but I don't exactly remember why it did not work. But the build failure is IMO about the 'gem install github-pages' anyway. Sorry I did not make a clearer minimal reproducer.
Anyway, thank you for your reaction! I eventually resolved my problems so this is mostly just feedback now.
(In reply to Pavel Raiskup from comment #2) > > As a sidenote, you could install `jekyll` from Fedora repositories, > > I initially tried, but I don't exactly remember why it did not work. But the > build failure is IMO about the 'gem install github-pages' anyway. Sorry I > did > not make a clearer minimal reproducer. It's fine. You could also give a try to my script, an attempt for using mixed upstream+downstream dependencies: https://github.com/developer-portal/website/blob/842f5580a8e94b3704bd44e33019faeb501fd027/setup.sh (In reply to Pavel Raiskup from comment #3) > Anyway, thank you for your reaction! I eventually resolved my problems so > this is mostly > just feedback now. Good to hear, thanks!
(In reply to Pavel Valena from comment #1) > That said, I'm personally inclined to simply add `Recommend` dependency to > `ruby-devel` package to better the experience for users (I hit this issue > from time to time as well). > > @vondruch WDYT? That probably make sense. Could you please make this reality?
I'm just curious why Recommends and not Requires. Is it more common that people install ruby-devel and they don't actually use those pre-configured flags?
Because redhat-rpm-config pulls in a lot of stuff which is certainly not relevant to Ruby development, but to packaging. Also, this is very likely issue just for projects which are using `mkmf` library for their configuration. Lastly, I don't want to hide this issue, because embedding and reusing the Ruby build options for other projects is not good idea. Speaking of which, I would actually like to see you report this to Eventmachine upstream, because of course Fedora is easy target, but we are just hostage. Ruby or Eventmachine should fix this ideally. Nobody cares to fix this properly, because we put workarounds in place. Maybe this is just pragmatic, or maybe not ...
> I would actually like to see you report this to Eventmachine upstream I have no idea what that is, so that reporter probably wouldn't be me. > Nobody cares to fix this properly, because we put workarounds in place. > Maybe this is just pragmatic, or maybe not ... Well the feedback I wanted to give you is that Fedora here is likely special, because (my guess) nobody else poisons the ruby flags with '/usr/lib/rpm/redhat/redhat-hardened-cc1' file. So to me it was not acceptable that basic things like 'gem install github-pages' do not work _by default_ on Fedora. Though, I can accept that Recommends would fix my use-case so if you claim that this is enough, I fully trust you.
(In reply to Pavel Raiskup from comment #8) > > I would actually like to see you report this to Eventmachine upstream > > I have no idea what that is, so that reporter probably wouldn't be me. That is the package you have tried to install. If you were able to figure out `cat /usr/local/lib64/gems/ruby/eventmachine-1.2.7/mkmf.log`, I think you could figure how to report something upstream, but ... ;) > > Nobody cares to fix this properly, because we put workarounds in place. > > Maybe this is just pragmatic, or maybe not ... > > Well the feedback I wanted to give you is that Fedora here is likely > special, because (my guess) nobody else poisons the ruby flags > with '/usr/lib/rpm/redhat/redhat-hardened-cc1' file. So to me it was > not acceptable that basic things like 'gem install github-pages' do not > work _by default_ on Fedora. It depends. Of course I have tried to convince the toolchain folks to stop doing this or provide better option to make the build configuration globally available, because there is no reason to keep different build settings to build some package via build system and use different settings to build the package locally. But there are certainly gaps in the tooling, which makes this hard. After all, not only Ruby suffers this issue (e.g. bug 1218294) > > Though, I can accept that Recommends would fix my use-case so if you > claim that this is enough, I fully trust you.
FEDORA-2020-f65087f3c4 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-439d75657b has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.