Re: Proposal to reduce anti-bundling requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 09/14/2015 07:08 AM, Josef Stribny wrote:
On 09/12/2015 12:41 AM, Jóhann B. Guðmundsson wrote:


On 09/11/2015 09:09 PM, Orion Poplawski wrote:
What does Fedora users gain with "dnf
install rails" or "dnf install ipython" versus "gem install rails" and "pip
install ipython"?

This indeed is very good question.

I'm not sure how things are elsewhere in the world but in the case of gem's on a rock in the middle of the north atlantic ocean , everybody is using bundler with nobody wanting to go back to non existing or not current gem's in distributions and or having to manually chase down components and resolve their dependency's.

They prefer spending that time actually hacking or drinking beer or both.

JBG
I would argue that the most valuable thing apart from the security tracking is that you can properly specify _all_ dependencies the gem actually have. This is a big one for at least few reasons:

1, end-users don't have to go read README to know what to install so that the software actually starts working
2, avoids compilation errors due to the missing header files or conflicts
3, installation is faster and more predictable

If someone has a problem with installing a gem, he/she can install rubygem-* package on Fedora and it's done (they can easily combine them with upstream gems). It's also quite nice that a beginner can just dnf install some framework if he just want to quickly try/evalute it, but does not want to spend afternoon hunting installation issues. This seems less relevant for experience people, e.g. I know how to fix problems with Ruby, but when I need to do a little of Python work I prefer to install Fedora packages rather than trying to make pip work for me.

But generally there are other (small) things as well...you don't need to install any junk like -devel packages on your system, you can track all your software with rpm/dnf (e.g. you can rollback a transaction), the gem can come with man pages, etc.

Perhaps in the past that workflow you point out here above was relevant ( to the "market" ) but people and companies ( here ) want to deploy Rails app to a container ( usually docker ) or a vm which has all of the app’s dependencies ( and they are using bundler for that application itself ) fully test the app in the container ( or a vm ), then ship the container ( or the vm ) to their production host(s) and or make available for their customers or the end users to use when they are ready and stick to supporting that container ( or vm ) image/setup only ( which addresses completely your 1,2,3 points there ) not the gazillion linux distribution out there and their package management system and formats apt, ­ aptitude ­ dselect ­ ubuntu software center,dnf,yum,apt-rpm,poldek, up2date, urpmi, zypp,slapt­-get,slackpkg,zendo,netpkg,swaret,appbrowser,­ conary,equo,pkgutils,pacman ­ petget, ­ pisi,portage ­ smart package manager, steam,tazpkg, upkg ( and probably bunch of others that I have forgot to mention ) and the downstream distribution policy's that go along with them.

Sorry to say but developers and companies here ( perhaps elsewhere as well ), have had their fill with Linux, it's fragmentation and it's freedoom of choice and trying to support all that ( and I can fully understand them ).

They simply have welcomed their new container overlords and are using only the recommended upstream method for installing for their application ( pip,gem etc since developers can use the upstream support community for those ) in those container images, followed by a strong attitude of use it ( their produced container/vm image not some downstream shipped/provided "package" ) or "take your freedom of choice and get lost, we are done trying to support and play the "X-factor of linux distributions" game. "

And once the "market" has ( started ) taken a stance ( moving away from downstream provided package of their components since it does not work due to the fragmentation in the linux ecosystem ) it's irrelevant what I think or you think or distributions think or implement locally beside providing the underlying structure to run their application for the sole purpose of being relevant as an platform for deployment ( which today is basically any distribution that ships systemd ).

JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux