Skip to content

It would be nice if you could avoid bundling 3rd party libraries #15

voxik opened this Issue Jan 27, 2012 · 12 comments

9 participants

voxik commented Jan 27, 2012


Trying to package journey for Fedora, I have noticed that you bundle 3rd party libraries, namely D3 and may be others (what is the origin of fsm.js?). Since Fedora prohibits bundling of libraries for good reasons [1], could you please consider removal of this library?

Also, I have the feeling that this is not essential functionality, so may be move into some optional gem would be nice.



Ruby on Rails member

I will keep these. I authored fsm.js, d3.js comes from here and looks to be free, so I will fix this ticket by including his license.

voxik commented Jan 28, 2012

License is one thing, but bundling is wrong and it makes harder to package this gem (and subsequently RoR) into Fedora (as well as other distributions, there are similar restrictions in Debian). Later, we have to find a way how to remove the bundled sources and use the upstream one packaged probably in separate package in Fedora. It does not help neither users nor packagers nor upstream.

Ruby on Rails member
NZKoz commented Jan 28, 2012

You have the ability to bundle patches with your spec files, it's not difficult to work around this for your case. I don't see any reason to address this barring some non-theoretical issue that impacts actual users, not packagers, of the library.


Open source is free, it is made by those who sacrifice their time to help others when they don't have to, and have no obligation to do so. They are not charging you and because of that I think it's unfair to demand something from them. I don't even see a thank you anywhere in your demands.


Firstly I'd like to say on record that yum is a peice of crap. Secondly nobody actually wants this in fedora. There is no need. You only need to include bundler so it's kinda pointless!


what's fedora, is that thing indiana jones wears ?


Hi @voxik, if I am not mistaken that rule is actually aimed at binaries. I understand that you want to be able to maintain binaries in one single place only. The libraries you are referring to in this project are javascript files, I do not see how those are relevant in any way to the security of your distribution? Those files are only ever run in the context of a browser, so how could that in any way affect safety/security?

Secondly, if those files are not allowed to be included, I have no idea how to express the dependencies otherwise.

The level of detail you are exercising here is a bit baffling to me.

NoICE commented Jan 29, 2012

... so now you would need to have fsm.js in gem called 'fsm'? or what?

that debian-bundling-gems or fedora-bundling-gems is SH*TTY altogether.

Why do you need aptitude or yum to handle dependencies of packages when there are rubygems that does this pretty well?

I also hate this sh*t on debian, running gem update --system gives you: You can't update RubyGems. Use aptitude. OMG!

I wonder if someone acutally uses rubygems/ruby/gems from aptitude/yum repositories. Fu*k NO!

voxik commented Jan 29, 2012

Sorry gentleman, I didn't want to flame about benefits of package managers. If you don't want to use them, please don't.

Now back to the topic.

  • Security consideration is of course one point of the reason why not bundle. Believing that something running in browser is secure just because of that seems to be short-sighted, although it is definitely quite secure.

  • Second point is of course space. Yes, we have terabytes harddrives, so we can waste, but on the other side, there are embedded devices etc. An why to have more than copy of library on your disk anyway?

  • If you want to check proper functionality of some library, it is nice to have it just on one place. Why to check if D3 is working in journey and in some other project which bundles it on other place. Why to fix some bug in million of places if I could fix it on one place etc.


sorry @voxik i don't agree. i understand / appreciate your efforts tho'

  1. security: you should know what you're bundling before you deploy your app. if you don't you probably deserve what you get.
  2. space: you can always use system gems using bundler if you want to.
  3. i'd rather have library isolation so i know some random version upgrade will not break my app.

perl community has talked about CPAN vs package management over and over again and i'm pretty sure there are a few long perlmonks threads on this topic which might shed light on advantages and disadvantages of both approaches.

voxik commented Jan 29, 2012

@deepfryed Please, if you feels that you have to convince me, contact me by email. This is not the place where we should discuss it. Thank you.


For what it's worth (nothing apparently.) Linux distributions insisting on packaging their own Gems, and ignoring the package manager eco system of the software they offer is insane, frustrating and never works. It would be preferable if these distributions would focus on their own problems; and allow us to solve our own.

@tenderlove tenderlove closed this in d0e3dfd Feb 8, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.