| |||||||||||||
|
| |||||||||||||
Too much choiceToo much choicePosted Jan 20, 2008 11:30 UTC (Sun) by michaeljt (subscriber, #39183)In reply to: Too much choice by jhs Parent article: Fedora developers on PackageKit
That is actually also a kernel API/ABI-related problem. If you try them out, you will find that many of the rpms and debs on the web page will install on different distributions (in fact, you could get by with one of the debs and two or three of the rpms). But since each distribution comes with different kernel versions, the distribution packages also contain pre-built kernel modules so that the people installing do not need to build their own. If someone does install a package which does not contain modules for their kernel though, and if they have gcc, kernel headers and friends installed, the right module will be built during the installation.
(Log in to post comments)
Too much choice Posted Jan 20, 2008 12:03 UTC (Sun) by jhs (subscriber, #12429) [Link] That's a good point, and I'm sure a product like VirtualBox is particularly sensitive to kernel API/ABI changes. Kernel developers don't want a stable API and ABI, and I think they make their case well. But there is still a problem that distributing software for Linux is hard, and the whole community suffers because of that. For free software projects (or at least software distributed in source form), the changing APIs and ABIs aren't the only problem: boot scripts, SELinux, firewalls, mountpoints, authentication back-ends, and dependencies (to name but a few) must all be considered when packaging software for Linux. Again, I don't think I have the answer, I just think it needs broad discussion. But in my opinion, a package-building wizard that works for >= 90% of ISVs is sorely needed. But to be successful it will probably require development and maintenance from experts from all the major distributions. We need a way to get all the benefit from the package systems (updates, dependability, maintainability, scalability, dependency tracking, authentication, etc.) but still make it a no-brainer for (most) ISVs to ship their software on "Linux." We need to shed ourselves of this bottleneck that is packagers for every distro. Why can't third-party software catch on among the masses and *then* Canonical decides to make *their* own package to make it really sharp and integrated (probably brown in color of course)?
Too much choice Posted Jan 20, 2008 14:51 UTC (Sun) by michaeljt (subscriber, #39183) [Link] I think that my current packaging ideal would be as follows. The package developer creates a source meta-package using some reasonably easy-to-understand system which can build to (source and binary) rpm, deb and similar targets. The developer would of course still need to do a build on a few different systems (which could however be virtual machines or chroot jails) to get a set of packages which will install on most distributions. Then the people who would otherwise have packaged the software for distributions can simply liaise with the developer to make sure that the meta package complies with any distribution policies. If source is available, distributions could do automatic rebuilds of the source debs and rpms when they add the software to their repositories. I am planning on giving something like this a try when I have time.
Too much choice Posted Jan 24, 2008 21:02 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Each distribution has its own "ABI":
Too much choice Posted Jan 25, 2008 8:49 UTC (Fri) by michaeljt (subscriber, #39183) [Link] This is true, but it is still possible to produce a package which will work just about everywhere (take a look at the VirtualBox "all distributions" installer for a proof of concept, putting aside the merits and weaknesses of the implementation). It is certainly quite a bit of work, but that is at least in part due to lack of experience in the field - I think that someone who has done it once would be able to do it again with much less effort.
Too much choice Posted Jan 21, 2008 3:50 UTC (Mon) by salimma (subscriber, #34460) [Link] That is what DKMS is for, surely.
Too much choice Posted Jan 21, 2008 6:17 UTC (Mon) by michaeljt (subscriber, #39183) [Link] DKMS is something I hear of once every six months. Is it really in use? And if so, how much overhead does it mean for end users?
Too much choice Posted Jan 22, 2008 0:40 UTC (Tue) by salimma (subscriber, #34460) [Link] It's used by at least one popular third-party repository for Fedora (FreshRPMS), and since it was developed by Dell, presumably the repositories that Dell host to support their Linux machines use DKMS for kernel modules. The only overhead is that you need a compiler and the kernel headers installed. (Oh, and on Fedora, right now, it cannot clean up old modules when the corresponding kernel is removed. On Debian/Ubuntu this works, and they're working to port the fix)
|
|
||||||||||||