| |||||||||||||
|
| |||||||||||||
Too much choiceToo much choicePosted Jan 18, 2008 23:24 UTC (Fri) by khim (subscriber, #9252)In reply to: Fedora developers on PackageKit by alecs1 Parent article: Fedora developers on PackageKit
Take a look from ISV's side. Debian packages work great - if you can create separate packages fro Debian stable, Debian testing, Debian unstable, Ubuntu 6.06, Ubuntu 7.04, Ubuntu 7.10. Argh. That's just for Debian! For RPM-based distributions you need 10 more packages. This is real shame of Linux. I mean: sure it's great that guys from Opera are producing huge number of versions tuned for all popular distributions. The fact that they need to do this is a shame. Without ISV support Linux will never will the battle for Desktop and ISV will not support Linux till it's easy to create simple installable package. And no, "./confugure ; make ; make install" is NOT a good way to install package not included in your repository. And if you think 10'000 different bank clients will be nice addition to RedHat's or Ubuntu's repository then you are clearly mistaken... Autopackage is so totally bad it's not even funny, but it does not make problem less real...
(Log in to post comments)
Too much choice Posted Jan 19, 2008 0:29 UTC (Sat) by jwb (guest, #15467) [Link] That's great, but I don't want ISV packages coming anywhere near my system. It is fine if the ISVs want to provide software, but the packages should be created by experts who know what they are doing, like all the other packages on my Ubuntu system. I do not trust software vendors to understand how to package software for Linux. It's that simple.
Too much choice Posted Jan 20, 2008 10:18 UTC (Sun) by jhs (subscriber, #12429) [Link] 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. The reality is that this is a case-by-case situation. And as I said in my other reply in this thread, the current package system does not scale. Nobody is satisfied: distributions can only get as much software on their platform as they have resources to make packages for; ISVs are frustrated with the effort it takes just to get the software in front of the user's eyes; and users are frustrated because it's hard to find and install software for their system easily. In some situations, like servers and secure environments, I fully support packaging and the good tight integration that comes with it. But free software is about choice, and right now, there is no choice for software distribution. Everybody just has to bite the bullet.
Too much choice Posted Jan 20, 2008 12:12 UTC (Sun) by jmtapio (guest, #23124) [Link] 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.
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.
Too much choice Posted Jan 20, 2008 15:57 UTC (Sun) by robilad (guest, #27163) [Link] It's impossible that authors know much about most of the platforms their software is being distributed on, due to factors like amount of choice in platforms, and access to them, or in case of ISVs, the platforms they make money from, and are willing to support, and the rest. A system that puts authors above distributors is going to fail, as it puts people who have next to no idea about the end user's environment in charge over those that do.
Too much choice Posted Jan 21, 2008 12:14 UTC (Mon) by kleptog (subscriber, #1183) [Link] Not sure if this is such a big deal, Things like Java and acrobat have been distributed as fancy tarballs for ages. All ISVs need to do is put up a tarball with a description of system requirements and people will make installers for various systems for you, no charge. If you as ISV stick to using LSB libc and other standard libraries you really shouldn't have any problems....
Too much choice Posted Jan 21, 2008 12:59 UTC (Mon) by robilad (guest, #27163) [Link] Java has been an amusingly painful story, if you look at the trouble the debian/jpackage/gentoo folks have been going through to make the binary blobs fit into the distributions, from in-the-middle-of-the-night updates to the tarballs by the vendors without a version change breaking md5 sums all over the place, to the inability to fetch the tarballs directly legally without interacting with a licensing mechanism, to breakage due to binary ABI changes , and a whole lot of other fun war stories the bug trackers and change logs can tell.
Too much choice Posted Jan 19, 2008 0:38 UTC (Sat) by man_ls (subscriber, #15091) [Link] ISV: "We have some nice software for you."Debian: "Just show us your packages so we know we can trust you." ISV: "Packages? We don't need no stinking packages!" Shooting ensues.
...or too few resources? Posted Jan 19, 2008 0:55 UTC (Sat) by jd (guest, #26381) [Link] I agree with the sentiment, but not with the problem. If the binaries are statically linked or the libraries are provided and installed if not already globally provided (using LD_LIBRARY_PATH or one of the other loader tricks to use local libraries where you need to force a version), you can indeed provide one installation that will work on every distro.Or you could compile to a shim layer and provide a distro-specific abstraction layer or shim. The advantage of this approach is that you would then have one x86 binary for all x86-based operating systems, using really just an extension of the IBCS module idea and the WINE approach. Then a port is nothing more than adapting an existing shim and compiling that shim. The program itself would only ever be compiled once per version. Likewise, a change to the application would only require recompiling the application, the shims would not be affected. A third option would be for ISVs to more actively adopt the approach of licensing out building for commercial distros, so that they only have to focus on a very narrow range of builds for systems they want supported and which can't (for whatever reason) support themselves. What do all these three things have in common? They tie up resources. The first ties up much more disk space and much more bandwidth. The second ties up a considerable amount of additional manpower. The third ties up money. They are all perfectly achievable, but only if someone invests the resources needed. No resources, no transparent multi-platform support. People provide the multiple installation packages, then, not because they have to but because they have decided that they do not wish to invest the resouces in any of the alternative solutions that exist. It is a choice, not a requirement. As for the package builder packages - we really do have enough of those, I think, and we have far too few abstraction libraries that can reduce the need for vast numbers of differently-configured packages. Again, not because it's impossible, but because that's not what people are developing. Package development kits are the right solution if, in fact, packaging is the right problem. Even a perfect solution is only helpful if the actual, underlying problem is something in the class of problems the solution is designed for. I have always been convinced that this is, in fact, the wrong problem, which is why none of the solutions end up really solving very much. Of course, this entire line of reasoning only applies for code that can be made portable by correctly designing and implementing it. Some code is inherently non-portable, because it relies on too many highly implementation-specific details of what it is working with. In other cases, a portable solution is possible but so sub-optimal for any system that it is no longer worth using. Anything that is not in those two categories can be written and compiled for a specific instruction set and word size. (And endienness, in the case of MIPS processors, as they can be switched at boot time.) Everything else can be hidden from the program, making it unnecessary for the program to know anything else.
...or too few resources? Posted Jan 19, 2008 3:00 UTC (Sat) by raven667 (subscriber, #5198) [Link] A third option would be for ISVs to more actively adopt the approach of licensing out building for commercial distros, so that they only have to focus on a very narrow range of builds for systems they want supported and which can't (for whatever reason) support themselves. This is the only kind of idea I see gaining any traction. I know that Novell has available a very comprehensive automated build environment and as I recall IBM does too. RedHat has their RedHat Exchange which kind of speaks toward this issue assuming that they provide some editorial control over the packaging of the software they resell. Distributors have to reach out, maybe even at a bit of a loss, to ISVs and help them make packages that don't suck because it affects the perception of the distributors entire ecosystem. RPM hell is not what a distributor wants to be known for.
...or too few resources? Posted Jan 19, 2008 16:02 UTC (Sat) by vonbrand (subscriber, #4458) [Link] This is exactly the same discussion as the one on Stable API on the Linux kernel.
I've messed around with a few different distributions, and the differences between distributions are large, and if you look not only at ABI differences but also at packaging guidelines (what goes into the main package, what goes into a
deb hell : Posted Jan 20, 2008 7:34 UTC (Sun) by muwlgr (guest, #35359) [Link] now there is one. Debian and Ubuntu have diverged their repositories far enough so that it's not easy to install .debs between them (however it's still not hard to rebuild them from the source). Earlier, the same could be said about Debian vs Stormix. Overall, as the policy becomes less strict and less centralized, the hell ensues.
Assuming you're right Posted Jan 19, 2008 19:23 UTC (Sat) by lakeland (subscriber, #1157) [Link] Wouldn't the solution to that problem be some sort of automatic package builder which takes in one input package and produces about a hundred packages for all sorts of distributions and versions? I mean, I'm not sure I agree with the problem definition you've given, but it does seem that most of the commercial software I've tried for Linux works that way rather than working with packages... So, the solution to that appears to be to make it easier to produce proper packages for every distribution, rather than producing a sorta meta package... doesn't it?
Assuming you're right Posted Jan 24, 2008 20:44 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Creating that "automated package builder" (and then keeping it up to snuff WRT a few hundred distributions) is surely much harder than just let one guy hash it out for each package at each end...
Too much choice Posted Jan 20, 2008 10:02 UTC (Sun) by jhs (subscriber, #12429) [Link] I could not agree more! I did not know anybody else thought this way! Every time I think about distributing software for Linux I want to scream! I have developed a lot of software for Linux as an ISV, and I can say that packaging is the worst part of making software for Linux. khim, add the VirtualBox download page to your shame list. I have packaged plenty of software for all Linux distributions and for Solaris. I understand all the technical issues involved, and I understand how rpm/yum and deb/apt is technically far more advanced than the Windows. But the reality is, it is trivial to install third party software on Windows. This is one remaining area where Windows just works and Linux is woefully inadequate from the user perspective. I think there are several things to think about in order to reach a good mix of the advantages of Linux distribution packaging and Windows "mu-packaging" (i.e. no packaging or minimalist packaging).
FWIW, my favorite package system is: Solaris. Conceptually, packages are just tarballs with the standard preinst hooks and basic dependency tracking. Not too smart, not too dumb, and convenient for ISVs
Too much choice Posted Jan 20, 2008 10:57 UTC (Sun) by michaeljt (subscriber, #39183) [Link] > khim, add the VirtualBox download page to your shame list. Shame for VirtualBox, or for Linux packaging?
Too much choice Posted Jan 20, 2008 11:15 UTC (Sun) by jhs (subscriber, #12429) [Link] Linux packaging. Notice how Windows and OS X require one entry each, and Linux gets twenty-one, plus a walkthrough for installing through apt.
Too much choice Posted Jan 20, 2008 11:30 UTC (Sun) by michaeljt (subscriber, #39183) [Link] 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.
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)
Too much choice Posted Jan 20, 2008 16:30 UTC (Sun) by robilad (guest, #27163) [Link] Decentralized systems for shipping interdependant binaries don't work in practice, as sweet as they sound in theory. * you get metadata drift, * you get binary incompatible dependencies due to build time differences, * you lose any opportunity to QA the distribution as you no longer know what your dependency graph looks like, * you need to ship and support every (broken) version of a dependency someone has ever used as ISVs don't upgrade their dependencies unless they really, really have to, * etc. DLL hell, RPM hell, JAR hell, the phenomenon has many names. The only reason why Debian, Fedora, ports, or even CPAN scale so well is * they are centralized * they are source code based
Too much choice Posted Jan 21, 2008 4:24 UTC (Mon) by jhs (subscriber, #12429) [Link] I think these are all great points. Package frameworks are highly evolved, while package developers are talented and invaluable. The current package system is great for core components and for tight integration. Where there is a problem yet to be solved is with end-user applications which are not (yet) core components of the distro. Plenty of developers write end-user software that is an endpoint in the dependency graph. These developers want to reach as many new users as possible, so it would be great if they could trivially distribute software on the major distros. (Again, dependencies are only one issue: boot scripts, on-line documentation, iptables, inetd, cron, and other components must also be dealt with.) Much free software is built with Autotools to make its *source* portable on many platforms. But at the other end, it's not so easy to turn compiled binaries into packages for each distro and architecture. Ideally, end-user software could be distributed in "good enough" wizard-built packages that allow people to try the software out. If it looks like something is the new killer app, and Distro X decides to bundle it in their distro, then at that point they can work on their custom packages, ideally in cooperation with the upstream developer. It's all free software, of course!
Too much choice Posted Jan 21, 2008 12:25 UTC (Mon) by robilad (guest, #27163) [Link] Usually, if something is the killer app, someone volunteers to package it for their favorite distribution. You can encourage that as a pro-active upstream, and keep your packagers updated of important changes ahead of releases, for example.
Too much choice Posted Jan 24, 2008 21:07 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
Too much choice Posted Jan 26, 2008 11:46 UTC (Sat) by talex (subscriber, #19139) [Link] All the problems you listed also apply to centralised systems. e.g. if I create a .deb for Ubuntu that depends on other Ubuntu packages, what stops Ubuntu from updating their packages and causing exactly the same problems?"You need to ship and support every (broken) version of a dependency someone has ever used as ISVs don't upgrade their dependencies unless they really, really have to," I'd say this problem only applies to centralised systems. e.g. I might need to ship a fixed libpng with my Ubuntu package, but not with my Fedora package. In a decentralised system, I'd just link against the known-good Fedora version for both.
Too much choice Posted Jan 24, 2008 20:54 UTC (Thu) by vonbrand (subscriber, #4458) [Link]
Re: Windows: Sure, just stash everything you might need into the installer, and drop all onto the unsuspecting Re: Solaris: As always, it is very easy if the target is one, and tightly controlled to boot. Linux, with its literally hundreds of distributions, each with its own objectives and guidelines, is a quite different beast. That is exactly the key point, and the biggest strength of Linux (and, as this thread shows), source of a weakness too.
Too much choice Posted Jan 20, 2008 17:57 UTC (Sun) by michaeljt (subscriber, #39183) [Link] > Autopackage is so totally bad it's not even funny, but it does not make problem less real... But their web page is an excellent resource on binary compatibility issues on Linux, if you look past the ranting.
Too much choice? huh? Posted Jan 21, 2008 6:32 UTC (Mon) by grouch (guest, #27289) [Link]
No, thanks anyway. It has been a very long time since I felt the need to rent software. (That "V" in "ISV" stands for vendor, but they don't sell stuff). If that "vendor" is unwilling to provide source and a suitable free (libre) software license, I have no interest in their wares and certainly do not want them bumbling around in unknowable ways with my operating system.
Too much choice Posted Jan 21, 2008 9:34 UTC (Mon) by Jel (guest, #22988) [Link] You don't need "10 more packages". You need once source package, repository servers (ie, websites) and a few automated build scripts. Then you need to supply yum and apt uris to users. It's actually much easier than having to write an applet that sits in the windows systray and monitors for updates, informs the user, downloads them, etc. Even on windows, you have to worry about x86, x86-64, intel, amd, vista, xp, etc. It's just that on debian etc., the issue has been solved.
|
|
||||||||||||