Hi Aleksandar, You touched just tip of the iceberg unfortunately. This is not just about nokogiri vs mini-portile. In this case, it would lead just to installation of build-time package (useless for binary distribution), but there are other similar cases I can think of:
1) Platform specific dependencies, such as in rubygem-listen: https://src.fedoraproject.org/rpms/rubygem-listen/blob/master/f/rubygem-listen.spec#_43 there is now just "rb-fsevent" dependency, which is mac specific library, but in previous versions of listen, there used to be dependency on "rb-kqueue" which is BSD specific stuff and there used to be dependency even on some Windows library. We don't want to have useles libraries on Fedora and install useless dependencies. 2) Again from rubygem-listen: https://src.fedoraproject.org/rpms/rubygem-listen/blob/master/f/rubygem-listen.spec#_48 This depends on ruby_dep. Again, this not concern of Fedora. On specific Fedora is specific version of Ruby and what version of Ruby is available on Fedora is not concern of any application running on Fedora. Actually look at the naive code: https://github.com/e2/ruby_dep/blob/master/lib/ruby_dep/ruby_version.rb#L27 It says something about some version of Ruby, but it does not every version and it cannot know if our version of Ruby is vulnerable or not, unless you are going to suggest at the time we should stop patching vulnerabilities in Ruby. 3) And lets take look at rubygem-sdoc. This package changes dependency on json: https://src.fedoraproject.org/rpms/rubygem-sdoc/blob/master/f/rubygem-sdoc.spec#_52 This was even accepted upstream, but was not released yet. If you are using upstream sdoc, you would be forcing Fedora to ship old vulnerable version of json. Would you like that? All in all, on these three examples I tried to explain you that changes in our packages are inevitable. We are not doing them lightheartedly and I don't think we are happy about them. Also I hope that every time, they were brought upstream and some of theme were resolved while the other were not. But they are really necessary sometimes. To your original issue, I'll personally be unhappy if anything changes in rubygem-nokogiri in regard to miniportile ... Vít Dne 9.11.2017 v 12:55 Aleksandar Kostadinov napsal(a): > Hello, > > I understood recently that we modify some gem files in fedora in a > non-compatible way [1]. > > Namely nokogiri is stripped off mini-portile which is not needed for > building in Fedora. Unfortunately this change also affects ability of > an app with Gemfile.lock to be installed in a system different from > the development system. e.g. build Gemfile.lock on Fedora 26 but > installed in some other OS. > > IMO this is similar to forking the upstream package mgmt system and > puts developers on fedora into surprising situations. > > My proposal is to stop doing such modifications to gem files. We can > ship mini-portile and still build against system libraries. This will > allow seamless `bundler` package management no matter where > Gemfile.lock was created. > > If we find that some upstream gem is not well packaged, then we should > rather work with the upstream to have that fixed. This would align > with the usual strategy of Red Hat and Fedora to avoid shipping > non-upstream patches (unless they are critical importance). > > Regards, > Aleksandar > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1482641 > _______________________________________________ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
