| |||||||||||||
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaborationUntz: Results of the App Installer meeting, and some thoughts on cross-distro collaborationPosted Jan 26, 2011 12:05 UTC (Wed) by dgm (subscriber, #49227)In reply to: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration by michaeljt Parent article: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration
If you could do that it would mean you had proper dependencies before bundling. Why throw away all that information? Wouldn't it be better to just ship the packages unbundled and update as usual?
(Log in to post comments)
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 13:02 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
So Firefox should not bundle Xulrunner, and you should wait for Thunderbird to be ported to the new Xulrunner, or remove it from your system.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 27, 2011 2:26 UTC (Thu) by vonbrand (subscriber, #4458) [Link] So you ask for collaboration between distributions to be gotten by fobidding upstream packages to collaborate and share pieces... way to go.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 13:02 UTC (Wed) by kleptog (subscriber, #1183) [Link]
I think the real problem is that the app developers know the dependencies but have no way of ensuring that they're installed. Even if you know the package name in a particular distribution, there's no guarantee the version you want even exists there (see endless versions of libssl for example).
Binary compatibility is really hard and most people don't bother. About the only library I know that pays any attention to it glibc, which goes to great lengths to ensure you get the symbol you linked against rather than whatever version is newest. Most libraries just increase the version number and ship it.
Many of the problems are solved. For example, we all more or less agree on the FHS so files end up in more or less the same place. LSB was in principle a great idea, but obsolete before it was done. What you need is something moves much faster.
Lets suppose that a few of the faster distributions (e.g. Mandriva, Ubuntu & Fedora) got together once a year and drew up a list of the 50 most common libraries and agreed on versions they would ship. Each distribution would be free to provide other versions, as long as that particular version would also ship. This might help (or not :) ).
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 14:27 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
This is the old "we need a common platform" argument and whether it's true or not doesn't seem to be important because we don't seem any closer, today, to actually doing it than we were ten years ago. I don't know that you can get cats to march in a line that straight and I think other solutions should be explored instead.
Creating platforms is a problem that has been up to now in the domain of the distribution. Most non-enterprise distributions don't actually worry about it at all, much less do it (except by chance). To have a third party dictate (or suggest) a platform to distributions is hard because (a) the distributions don't know what a platform is and (b) they won't like dancing to someone else's tune, especially if the advertised payoff is "More work for you but less work for people who are not you."
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 26, 2011 14:34 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> If you could do that it would mean you had proper dependencies before bundling. Why throw away all that information? Wouldn't it be better to just ship the packages unbundled and update as usual?
This is just my answer, not an answer from a wise person who has thought much about the matter. Mainly, I would say, because it reduces complexity. A FLOSS-style binary distribution requires masses of testing to ensure that every component works well with every other. Using bundles with reduced dependencies reduces the testing burden on the maintainer, even before you worry about cross-distribution installation.
Then there is the traditional argument that bundling dependencies frees you from worrying what is or is not available on the user's distribution. You just bundle it yourself, test your package and are happy.
Plus my personal feeling is that the package database on a FLOSS system is always a potential place for things to go wrong. Thankfully I think this has only hit me once (or maybe twice), but if it does get corrupt you are in for a massive fixing (or re-installing) session that would be much less painful on a system mainly using bundles. And from a cleanliness point of view, it is much easier to have an overview of what a system mainly based on bundles has on it. I must admit that that last point is what I find most attractive about bundles - they give you much more of a feeling of being in control of your system while (by) structuring (if not reducing) its overall complexity.
Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration Posted Jan 27, 2011 2:17 UTC (Thu) by vonbrand (subscriber, #4458) [Link] Bundles are either massive duplication (and innumerable opportunities for security (and other) bugs that get never fixed) or require something like the current dependency handling system, but on weapons-grade steroids (you'd have to track not only one set of dependencies, but potentially dependencies for each single package in the system separately). I just don't see anything but downsides. Yes, the package database is a single point of failure for a Linux distribution. Yes, in the 15 or so years of Red Hat (and derivatives) use I did have my half dozen problems with broken RPM databases, but AFAIR just once there was no reasonable way to fix it without a full reinstall (and that was due to a disk problem, that thrashed the system regardless). Sure, fixing the database wasn't trivial; but the technology used has gotten way better over time, the last thrashed RPM database was quite some time back.
|
|||||||||||||