Too much choice [LWN.net]

Too much choice

Posted Jan 20, 2008 12:12 UTC (Sun) by jmtapio (guest, #23124)
In reply to: Too much choice by jhs
Parent article: Fedora developers on PackageKit

I think this is a chauvinist comment. You are insisting on having middle-men modify the software that the author wrote before you use it. It's possible that the authors of the software know better how to integrate it into a distribution than a volunteer packager in some cases.

While it is possible that some authors can be better at integrating than some of the packagers, in my personal experience packagers usually are better at integration than the original authors. I believe this is because ultimately the authors are more interested on their own specific software, its quality and functionality. Packagers on the other hand are interested in making the whole system coherent. This includes stuff like placing documentation where it is supposed to be, integrating startup-scripts, wrappers, registering this and that to the system and so on. All of that is usually secondary for the authors themselves.

(Log in to post comments)

Too much choice

Posted Jan 22, 2008 12:58 UTC (Tue) by Tom2 (guest, #43780) [Link]

Perhaps this is a circular argument?

1. Distributions fail to provide tools to let ISV's provide software that integrates easily
with their distribution.

2. ISV's therefore produce packages that don't integrate well.

3. Users blame ISVs, and applaud distributions for their centralised 
packagers, since they clearly work much better.

Too much choice

Posted Jan 24, 2008 21:18 UTC (Thu) by vmole (guest, #111) [Link]

1. Distributions fail to provide tools to let ISV's provide software that integrates easily with their distribution.

For Debian-based distributions, this is simply false. The tools (dpkg, debhelper, etc.) are there, and the documentation is there. The facilities to ask questions are there. And you don't have to build separate packages for each distribution variation -- it takes real effort to build packages that install and run on stable that won't install and run on testing or unstable.

Yes, it takes time to read the docs, and learn the basic packaging tools. But if you're not willing to do that, then why on earth would I trust your FooBarPkg package not to overwrite some critical library file or configuration? And if you don't want to take the time to integrate with the basic distribution (which might be a reasonable decision), then there is a long established, well-worked out scheme: unpack the tar.gz file under /opt/pkgname, and do whatever the hell you want under there. Anything in between is silly and dangerous.