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 , 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.
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.
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.
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 ?
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.
... 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!
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'
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.
@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.
moving d3.js to a hosted solution. fixes #15