On Sun, Sep 13, 2015 at 10:05 AM, Sérgio Basto <sergio@serjux.com> wrote:
On Sex, 2015-09-11 at 22:41 +0000, 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 don't think so , if foo package have a security hole , dnf update will
have an update when pip or gem install don't .
Other big reason is if you need foo package to build foo2 package ,
system doesn't know the existence of foo package with pip or gem ,
neither can force the installation of it when is in a another system.



> 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

--
Sérgio M. B.

​Personally, I think there's still a lot of value to the Linux distribution model, especially in regards to security and sanity (which unbundling enables). However, unlike in the early days where distributions worked with these communities more and had a lot more say in the development of mechanisms in which libraries are used, newer frameworks, environments, programming languages are being developed in environments where ​the developer has (perhaps somewhat rightly) assumed that the distribution wouldn't care to be an enabler for their platform. 

My personal view is that this has happened along the shift from Mandrake/Red Hat/SUSE to Debian/Ubuntu as the popular distribution families. The former cares a lot more about upstream integration than the latter. Take for example Debian's systemd package (I mention this because I got bitten by it). It actually applies a bunch of patches that effectively change much of its behavior in regressive ways. As one example, systemd-udevd is patched to enable a racey behavior because the fix was considered regressive in functionality. There are tons of other examples out there. As the Debian/Ubuntu environment became more popular, so did bundling in non webapp software. It's much more difficult to get software into a globally usable form in that environment, and their people aren't pushing as hard as we do for that.

Additionally, it's quite difficult to get new software into the Debian/Ubuntu main distribution, which practically compels developers to think in different ways to get what they need to get hacking. Consequently, we now have languages like Go that don't even have a concept of shared libraries. Things must be statically linked in order to work. Even if a language like Go did have it, it would be impractical for users of Go programs to be able to run them on Debian/Ubuntu because the distribution doesn't pull in new stuff mid-cycle like Fedora, openSUSE, and Mageia do. Of course, there are tools like the Open Build Service, but they are cumbersome to use unless you have a large team of people working on it.

And of course, there are purpose-built languages like PHP and JavaScript that lack built in functionality to support system modules. No one has developed a model that would enable people to be able to use system-packaged PHP libraries. With the advent of Node.js and PHP's (slowly) growing system manipulation capabilities, the onus has increasingly fallen on the distribution folks to get involved and develop systems that usefully enable system module models while retaining the necessary flexibility whenever it's needed.

In the PHP land, Composer somewhat gets you there, because it utilizes PHP namespacing capabilities to allow modules and libraries from the vendor directory. However, if someone were to build something that consumed composer.json/composer.lock data to depsolve at build to fill in Requires and generate the necessary loader data automatically, we might find PHP applications becoming easier to deal with. Eventually, it'd be nice to have something like %composer_install that reads the information, locates them in the system, and constructs the necessary loader information, and perhaps even installs the project code, though that might be tricky to pull off.

Node.js' npm is inspired in part by CPAN and PEAR, and I imagine that it imposes some constraints that make it easier to unbundle, but I don't know for sure, since I haven't worked with it.

I know that Fedora is working on a new developer portal site, but I don't know to what extent that Fedora/Red Hat does outreach and collaboration to development communities like the Go, PHP, JavaScript/Node.js, etc. ones. In my eyes, we also need to figure out how to make good RPM packaging easier and more attractive than bundling, especially with the advent of web technologies being used for local applications.


--
真実はいつも一つ!/ Always, there's only one truth!