Proposal to reduce anti-bundling requirements

[Jóhann B. Guðmundsson]

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