Proposal to reduce anti-bundling requirements

Vít Ondruch vondruch at redhat.com
Tue Sep 15 06:38:01 UTC 2015


Dne 14.9.2015 v 21:52 Orion Poplawski napsal(a):
> On 09/11/2015 07:51 AM, Vít Ondruch wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> Dne 10.9.2015 v 15:53 Stephen Gallagher napsal(a):
>>>  * Increases the available pool of software that can be packaged
>>> substantially (many modern languages such as Ruby and Go are
>>> realistically only functional with allowable bundling)
>> Not sure why you put Ruby into this group. There is no evidence that
>> bundling is more prominent in Ruby then in other languages. If your
>> judgment is based on existence of rubygem-bundler, then you completely
>> misunderstand purpose of the project.
> To bring up ruby - https://fedorahosted.org/fpc/ticket/560
>
> rubygem-bundler bundles rubygem-thor, rubygem-net-http-persistent, and
> rubygem-molinilio.
>
> From discussion with upstream here: https://github.com/bundler/bundler/issues/3647
>
> I get:
>
>
>     Bundler is meant to be installed as a gem.
>     The Bundler team does not provide support for installing or using Bundler
> as an OS package.
>     The way Ruby handles dependencies unfortunately forces us to modify and
> vendor Thor and Molinillo.
>     The public versions of Thor and Molinillo are not usable by Bundler.
> Trying to use them instead of the vendored versions will create certain
> situations where applications are completely broken and unable to function.
> Please don't do that.
>
> We're not going to change how we vendor things to make it easier to remove
> vendored code, because removing the vendored code will break both Bundler and
> applications that use Bundler.

Just to explain what was the original request, please check these three
loaders:

https://github.com/bundler/bundler/blob/master/lib/bundler/vendored_thor.rb
https://github.com/bundler/bundler/blob/master/lib/bundler/vendored_molinillo.rb
https://github.com/bundler/bundler/blob/master/lib/bundler/vendored_persistent.rb

You will find out, that they don't apply the same measures to all
bundled libraries and that was the original reason for the ticket.
Unfortunately, the discussion got derailed pretty quickly.

Moreover, they really don't understand what Fedora is trying to achieve,
what is the purpose of the distribution. And of course they don't
support "for installing or using Bundler as an OS package." as most of
other software does not provide the support. This is overstatement as in
many other discussions with upstream Bundler.

Nonetheless, Bundler solves real world issue and that is version
conflicts of libraries and hence everybody is using it.

>
>
> At this point I say fine, upstream actively doesn't want it shipped as an OS
> package, so let's just drop it.  Of course:
>
> # dnf repoquery --whatrequires rubygem-bundler --source --alldeps
> rOCCI-server-1.1.6-6.20150217git73409ea.fc24.src.rpm
> rubygem-appraisal-0.5.2-3.fc23.src.rpm
> rubygem-bundler-1.7.8-3.fc23.src.rpm
> rubygem-bundler_ext-0.4.0-2.fc23.src.rpm
> rubygem-gemnasium-parser-0.1.9-4.fc23.src.rpm
> rubygem-rails-4.2.4-1.fc24.src.rpm
> vagrant-1.7.4-1.fc24.src.rpm
>
> This means no rails or vagrant in Fedora.  But this is what has been driving
> some of my thinking lately.
>
> Now, perhaps upstream's real position is that they don't support it as an OS
> package *if the OS package is modified*.  This then brings us back to the
> question of is it okay to just ship the package as is in Fedora.  And maybe it
> is time to just stop caring so much about this issue.
>

The latest version of Bundler is the first one where I believe we cannot
simply unbundle the libraries and this should be judged as an exception
by FPC [1], but instead of granting exception, there are discussion
about removing Bundler from Fedora (or better no discussion at all).


Vít



[1] https://fedorahosted.org/fpc/ticket/560



More information about the devel mailing list