A while back, I wrote about a system called Autopackage, which attempted to solve some of the problems with software installation on Linux. I had some praise and a few criticisms of the project, and some of the autopackage people came by and discussed some of them. I still get new comments on that post every so often, mostly of the “if you don’t like autopackage, don’t use it” variety.
Autopackage has attracted a lot more criticism over time, and it seems that criticism has driven at least one autopackage person completely batty. Apparently, nearly everything violates their idea of how the world should work: package managers, Python, C++, the standard C library, the ELF executable file format, and the dynamic linker, at least.
Others have observed their poor attitude, and have pointed out inaccuracies.
The whole incident is frustrating. Autopackage does some things well. Their efforts to solve binary compatibility problems, for example, have resulted in some seriously cool utilities. But they seem to have an inflated opinion of themselves, and it closes their minds to working with others. With me, it was the idea that distributor support could possibly be desireable for users. This seemed to be a totally alien concept to them
I do want to emphasize Klik, though (from Erich’s link). It appears to solve many of the same problems, but without insisting that the entire software infrastructure behind Linux adapt to it.
I agree with you: I liked the idea of the project, until I kept seeing Mike Hearn (main developer) keep badmouthing distributions left and right, and being really inacurate when wanting to show how demented it is for the users to install software on gnu/linux. For example, that since there are 300+ distributions, so that means that a provider of software for gnu/linux would have to fill an entire CD to provide packages for all those distributions. In fact, when reduced to the main distributions which target the kind of user autopackage is targeting, the list narrows down to half a dozen packages, or a dozen if one wants encompass 99% of distributions casual users may be using. The fact that free software can be easily installed in each distribution (and getting more, and more easier) keeps being ignored, makes me wonder what kind of software is he talking about. Proprietary, perhaps?
Other times, he points at individual mistakes done by debian developers in packaging software as a sign for a complete distrust to packagers (even after they’ve been fixed a long time). As if a bad choice (in design or otherwise) done by an upstream developer would mean that they should disapear. He also fails to mention that indeed the other way around has ocurred many time, for example, cdrecord and the author’s rejection of every patch for dvd burning support. This was a case where distributions generally behaved in the interest of their users, by patching their distributed packages themselves. As a user, I find this balance rather reassuring.
In the end, I think this project is, but hope to be wrong, oriented to bring proprietary software developers to gnu/linux. Which would be ok, up until the point where it wants to remake the entire social fabric of developers, users, testers, packagers, translators, and “defenders of their users” that distributions provide (or in other words, get rid of it all).
I hope to be wrong in the same way you do: Present the various ideas the autopackage project has come up with to the various distributions, and work with them, not against them.
oh, and there are very good points (better than mine) in the blogs you linked to.
Well, good to know I’m “completely batty” for pointing out technical problems with the ABI stability of Python, C++ and the design of ELF itself. I guess you could have discussed these issues yourself, but prefer to simply throw insults around. Pot, meet kettle.
When people have hard, technical facts about ELF or the forking of the Python ABI by distributions then I’d be interested to see them. The blogs you linked to do not “point out inaccuracies”. Daniels post talks about something completely different to shlibdeps, which is what was being criticised, and the other blog doesn’t appear to contain any technical content at all, being simply a repeat of what you are saying.
It’s certainly true that the page in question had a bad attitude, however, it is as far as I’m aware the _only_ attempt to document the serious binary compatibility problems that Linux has. Did you seriously expect it to be butterflies and sunshine?
Mike’s not “completely batty”; he might be more abrasive about things than he might need to be to convince people that there IS a problem- but many of the things he’s talked to are for-real and ARE problems for _binary_ portability.
I work as a consultant for Linux Game Publishing and several other vendors and there’s all kinds of “fun” things that are going on out there in the Linux world:
glibc not even being reliable for the same version on two different distributions- in the recent past, things linked against 2.1 (which SHOULD be fine- 2.2, 2.3, and 2.4 technically should have the 2.1 ABI rulesets in them) would not work at all in Mandriva (outright crash at startup of the OpenGL layer- segfault in the constructor manipulating memory allegedly just allocated for the object) and comes up with a double free error in Fedora Core 4. Same glibc version. Radically different behavior. Do we have distributions “patching” the glibc layer here? Is it a lurking bug in optimizations? It’s broken- and for the same reason Mike’s calling it that.
Then there’s the glibc, C++, and ELF woes he mentioned- I’ve been bit by all of them. I can’t talk to the Python problem, but if what he’s saying is right, then it too is a fundamental problem.
You see, folks, the problem isn’t that the stuff doesn’t work- it’s that it all needs to be hand-crafted from the ground up. There’s _currently_ all kinds of issues with someone taking a binary built on Red Hat and moving it over to Mandriva or Debian. Issues that shouldn’t be. Mike’s being perhaps too harsh in his commentary- but it’s dead on with what is wrong. I can’t say for sure if his answers are good ones, but _SOMETHING_ needs to be done as not everything is going to be Open Sourced for some time to come and I’m only about a month or two away from startting put a wedge into one segment of Microsoft’s stranglehold on things. One substantive enough that we need some better answers quickly.
You guys may have missed my post about my new job. I now work for the Free Standards Group, the group with more experience in binary compatibility issues on Linux distributions than anyone else around. Including you.
We put out a set of applications as a part of our test suite that run on every LSB-compliant distribution (and even a few that aren’t). These are not trivial applications; they include Celestia, Apache, Tcl/Tk, and, yes, Python. We’re getting ready to release specifications for desktop apps, and will release serious desktop apps at the same time, Gaim and Scribus among them.
My experience with the FSG is what leads me to call you “completely batty”. I should probably add “completely ineffectual”. Have you read the comments about you from everyone else, such as those I link to? Do you think all these people are now going to follow you around? What, in short, did you expect everyone to do when they read your rants?
And while you rant, I and my colleagues at the FSG have been making real progress towards fixing some of the problems you mention, by describing and testing distro behavior and getting them to fix the problems we find. It’s not perfect, but it’s progress. How much progress has your rant produced?
I had this problem with you the last time I posted. You come out with, basically, InstallShield for Linux, and think this gives you the right to slam on everyone who doesn’t agree with your approach. Well, OK. Maybe someone will come along with a bit less of a chip on his shoulder and make your work relevant to the rest of us.
¿ What does klik for the binary compatibility problems ?
As far as I can tell, klik bundles all prerequisites as part of the klik “package”, so there are no issues (besides the potential large size).
When we had the Packaging Summit in Berlin last December, one of the klik guys gave a very good presentation. So, perhaps we can help the klik folks by providing a good baseline, and klik can help us by providing an alternative installation system.