On Wed, Apr 03, 2013 at 08:39:38PM +0200, Nicolas Mailhot wrote: > And that is just a rehash of the old "it's too much work to help the > upstreams of my deps to fix their stuff, I'll workaround it locally" > argument. > > That way of working does not scale. It's just a developer shortcut to > avoid paying his technical debts and push the problems to someone else > downstream. > (note that those developer problems are always caused by other developer > sloppy practices but they blame the distro environment that forces them to > do something about it). Besides, it is against Fedora's explicit goals. > > The root of the clashes between devs and system/distro people is that devs > are used to having layers of people they can dump un-sexy problems on (qa, > systems, support) while distro people tend to be more aware the next layer > is the user and system success is about not dumping problems on them. I agree with everything you say and think you're completely right about this, nevertheless here's a devil's advocate argument ... Several upstream communities have terrible development practices and are very resistant to change. That in itself wouldn't matter, but these same development communities also make software which is very popular. Distros that embrace and work with this software are going to be much more popular than those that don't, because at the end of the day the purpose of having an operating system is to run applications. So we have, I think, four choices: (1) embrace the software, allow it to be shipped (or even ship it ourselves), and don't care about the security problems (2) deal with the combinatorial security explosion of having multiple parallel versions of badly engineered packages installed, requiring loads of extra manpower (from where?!) (3) spend ages educating the upstream developers on best practices, and patching and fixing upstream software ourselves (4) don't embrace or ship this software, and risk obscurity I think #3 or #4 is where we are right now. None of this means we have to make odd changes to RPM however, since RPM can quite happily deal with the packaging problems already or at least with very minor enhancements. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
