-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2013 10:51 AM, Bruno Wolff III wrote: > On Mon, Jul 22, 2013 at 09:38:54 -0400, Matthew Miller > <mattdm@xxxxxxxxxxxxxxxxx> wrote: >> >> Obviously, no-bundled-libs is a crucial part of the packaging >> guidelines today. As a sysadmin, I know why it's important. This >> is not just a noble goal, but also something that pragmatically >> makes systems better. But, it's also keeping us from having >> software that people really use in Fedora. Chef and Hadoop are >> two big examples. This hurts us more than it helps the world. So, >> in some areas, we need a different approach. > > I'm a bit worried about this. We really want bundled libs to > eventually go away (for any particular bundled lib). This seems > like it could encourage permanently bundled libs. That is going to > make some packages conflicting for a very long time. (And the > conflicting packages may not be providing the same service, so that > you'd need to run two instances of Fedora to get both sets of > services.) I really agree with Matthew here. The value of unbundling from a maintenance perspective is obvious to *us*, but it's seen as limiting from the perspective of developers. Realize that the deployment model of an application developer is very different from that of an OS designed. If I am writing a new application, I want people to be able to use it. I want that application to run basically anywhere with the least amount of modification. Writing new features and fixing bugs in my application is where I want to spend my time. I'm not going to spend the effort to get my application to build on just one particular distribution. This means that packages for Fedora generally only get built when someone who is *already invested* in Fedora decides to spend the effort to put it there. By reducing the restrictions on what can be shipped (at certain rings), we open up the world to the application developers. We suddenly become an interesting target and something that they're willing to list on the project website. Right now, Fedora is facing a relevancy crisis. All of our packaging guidelines are written to address the needs of low-level systems applications, but the vast majority of open-source development has moved up the stack. For most hackers, the low-level is a _solved problem_. Sure, there are enhancements to be made, but for most people it's just already good enough. The real value to their environments is in the applications (and to a lesser extent, those application frameworks). At this point, it really becomes a simple cost-benefit analysis: If it takes me an extra 10% of my development time to conform to one distribution's policies or I can just bundle a copy of a library that I know works, I'm probably going to go the bundling route. If I'm *smart*, I'm probably also monitoring for vulnerabilities in those packages, but if I'm not, I'll get around to fixing it once someone reports such a vulnerability to me. That's a more efficient use of my time and it allows me to spend more time on delivering a *useful* product, possibly at the expense of a *secure* one. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHtVHkACgkQeiVVYja6o6NIzQCfYSWEqKuUlAk+jWmzcLALbz8n xPMAn1M6CWu9eHFdVLnN8/oYnvGvFJKV =aDhH -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
