Proposal to reduce anti-bundling requirements

[Neal Gompa]

On Sun, Sep 13, 2015 at 10:05 AM, Sérgio Basto <sergio at 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.
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150913/6f18da3b/attachment-0001.html>