Autopackage struggling to gain acceptance

By Bruce Byfield on February 12, 2007 (8:00:00 AM)

Share    Print    Comments   

Fourteen months ago, the Autopackage project was small and active, and members sounded optimistic about its success. Now, although the alternative installer project continues, progress has almost come to a halt. The #autopackage channel on sits vacant most days, the developer blogs cover almost anything except the project, and commits to the source code repository have become rare. Formally, the project is still alive, but the major contributors all agree that it is faltering. So what happened?

The answer reflects why many free and open source software (FOSS) projects fail, and the difficulties of introducing any major changes to the fundamental structure of Linux today.

As described in an article posted in 2005 on, Autopackage offers several advantages over native package systems. Designed primarily for use with desktop applications rather than for basic operating system files and utilities, it can be used to install software only to non-root accounts.

This is not only convenient, but also protects the system as a whole against malware. Unlike native packaging systems, it works on any distribution, and includes a interface that is at once attractive, powerful, and simple. Its documentation is also clear and organized. On the surface, Autopackage seems to have everything going for it.

Nor is the situation entirely negative. Xara Xtreme's releases are available in Autopackage format, and a Dutch tax software program was released as an Autopackage in 2005. Moreover, one of the most active Autopackage contributors, Isak Savo, says the project team has worked hard to encourage Autopackage's use.

Project members have made packages and sent them to projects in the hopes of finding maintainers, and pointed out the advantage of using Autopackage to make the latest software versions available quickly to users. Given a chance, they will happily argue Autopackage's merits in articles and blogs, and in mailing list discussions.

Yet, despite these efforts, the list of available packages has not grown much in the last year, and many packages, such as the one for the GIMP, are no longer current. Admittedly, not all uses of Autopackage are noted on the project Web site, as a search will quickly show. But, all too clearly, adoption of Autopackage is not increasing, and may even be regressing.

The problems with a small project

One of the most obvious problems for Autopackage is the small number of volunteers working on the project. Three developers contribute most of the code, although a number of others maintain specific packages. Of the three, Savo has recently graduated from university and found that work leaves him little time for FOSS development.

Similarly, Mike Hearn, one of the founders of the project and its major driving force, has taken a job at Google in the last year and is no longer active in the project. "I still handle email and take part in discussions," Hearn says, "But I don't write code any more or do any evangelism." Short-handed even in its heyday, Autopackage has only one member of the core team, Taj Morton, who is still active, and, so far, no one has volunteered to take on much of the work that has to be done.

To make matters worse, this shortage of volunteers occurs at a time when basic functionality is already coded, and much of what remains are bug-fixes. This kind of detail work often has trouble attracting volunteers in any project, partly because it is less interesting, and partly because it often requires greater expertise and attention to detail than the initial programming. Hearn has prepared a list of the main technical issues with Autopackage, but there are simply not enough people with both the expertise and the time to solve them.

As a result, Savo says, "we still are having problems with integration on some distributions." Nor, Savo notes, is there time to make changes that would make Autopackage appeal to independent software vendors, such as the ability to display an end-users license agreement. While most of these problems are ones that most developers for Linux must face, they are difficult obstacles for a project like Autopackage that faces a shortage of volunteers.

The conservatism of the distros

Along with the problems of a small project trying to tackle large problems, Autopackage also faces difficulties because of its explicit challenge to such a basic part of the operating system as software installation.

For one thing, Savo notes, many projects have no reason to consider Autopackage. "For large projects, the incentive to distribute as Autopackage is rather small, since they have dozens of packagers ready to package the app for every major distro anyway."

Moreover, as Robert Staudinger, the maintainer of the AbiWord autopackage, observes, "Distros are better maintained these days and a number of them are doing frequent releases." Under this regime, the argument that Autopackage can provide more timely releases for desktop applications is becoming less attractive. Used to the native package systems, many distributions, Hearn suggests, "over-estimate the cost and under-estimate the benefits" of a universal installer such as Autopackage, preferring to cling to what they know.

Furthermore, Staudinger suggests that experienced users, who understand native package systems, have little incentive to switch to a new system. "On the other hand," he says, "We've had many of the non biased newcomers just try alternative installers and continue using them if they work out well."

Such reactions are only aggravated by the fact that advocacy for Autopackage often turns into a specific critique of native package systems. On his blog, as well as at the Free Standard Group's Packaging Summit in December 2006, Hearn has critiqued native packaging systems as both out-dated and anti-democratic."The whole idea of packaging/installation is bogus and leftover from the times when software was distributed on floppy disks," Hearn claims. "The web 'instant activation' model is better but requires advances in client-side platforms first around streaming and security."

The problems with software installation, he continues, are similar to other architectural issues with Linux, such as drivers. He describes these problems as "not technical but rather due to cultural/social issues." After discussion with major distributions, he suggested in his presentation at the Packaging Summit that most distributions were too competitive to agree to the underlying changes that he believes are necessary.

In some aspects, Staudinger seems right about the conservatism that stands in the way of Autopackage's acceptance. Jeff Licquia, a Debian developer and an employee of the Linux Foundation, criticizes Autopackage for not working in conjunction with native package systems.

In another blog entry entitled "Autopackage goes insane," Licquia writes, "Apparently, nearly everything violates [Autopackage's] 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."

Criticism is especially strong from Debian developers, including Joey Hess, who described Autopackage as "designed by monkeys" from a technical perspective. However, the negative response is not confined to a single distribution: the Gentoo Development Guide, for instance describes Autopackage as "totally unsuitable for Gentoo systems."

Hearn's statements may explain the resistance to Autopackage's acceptance, but clearly they also help to fuel it. As Staudinger says, "One of the issues with Autopackage is the controversy that surrounds it." From Staudinger's perspective, the largest problem that Autopackage faces may be simply that "many people are just annoyed by the fact that Mike Hearn openly addressed some Linux core issues."

Looking ahead

Autopackage is not officially dead, and development on the project is continuing, albeit slowly. All the same, between the logistical problems and the controversy generated by its advocacy, its moment seems to have passed as its lead programmer became increasingly disillusioned.

Recently, Hearn has shown less interest in continuing his direct criticism of Linux architecture, choosing to approach the issues more indirectly by focusing on the need for standardization instead. However, he remains pessimistic about any fundamental changes.

Talking about the issues that surround Autopackage, Hearn says, "I eventually concluded that Linux was never going to make the big improvements to desktop computing that I wanted to see, and, therefore, that it'd never get non-trivial market share. That's one reason why these days I work on servers for Google instead of client-side stuff for a Linux company."

If Hearn is correct, the real lesson of Autopackage is not how to improve software installation, but the difficulty -- perhaps the impossibility -- of large-scale changes in Linux architecture this late in its history. It's a sobering, disappointing conclusion to a project that once seemed so promising.

Bruce Byfield is a computer journalist who writes regularly for NewsForge,, and IT Manager's Journal.

Bruce Byfield is a computer journalist who writes regularly for and IT Manager's Journal.

Share    Print    Comments   


on Autopackage struggling to gain acceptance

Note: Comments are owned by the poster. We are not responsible for their content.

A solution in search of a problem

Posted by: Anonymous Coward on February 13, 2007 03:44 AM
Autopackage is going nowhere because it's a solution in search of a problem. Lots of people groan about how hard it is to install packages in Linux. However, the reality is that installing packages in Linux is, for the most part, remarkably simple. Often the complaint is that it's hard to install apps that are not packaged for your distro, but many apps (Google Earth, Skype, Moneydance to name a few) show that anybody with some decent shell-scripting skills can write a sh script that installs a binary package for non-root use. The current Linux package distribution methods work fine, and that's why Autopackage has gotten nowhere.


Re:A solution in search of a problem

Posted by: Anonymous Coward on February 13, 2007 06:32 AM
I rather want an unified way of doing it, than each project have some hacked-up shell scripts, that wont even uninstall. And have the software scattered all around the system.
Just because something works, doesn't mean its good.

I want to be able to install/uninstall applications from the console and via a GUI.

I want to be able to uninstall all my software from an centralized tool.


Re:A solution in search of a problem

Posted by: Anonymous Coward on February 14, 2007 09:49 PM
Then you want to use your distro native package manager, I guess.


Re:A solution in search of a problem

Posted by: Anonymous Coward on February 13, 2007 03:13 PM
And a wannabe solution at that. I tried it one time. Never again. It takes longer to tell autopackage what you're trying to do that it takes to configure, make & checkinstall.

Not to mention that installing autopackage itself was a headache. When someone wants to convince me about ease of use, they should start with their own product.

Slackware has the right idea. Keep it simple.


Re:A solution in search of a problem

Posted by: Anonymous Coward on February 13, 2007 06:38 PM
You sir are a know-nothing moron. Enjoy that.

There are a miriad of issues with the current Linux packaging model. The biggest for developers is that it is a support nightmare, with 50 different packages to have people demanding support for, it becomes impossible to offer any level of decent support.

Also you frankly lie that there is packages available for all apps for all distros. Fall behind on your SuSE version? Good luck. Too cutting edge with your SuSE version? Good luck. Want a package on the day of release? Good luck. Want a package for something obscure? Good luck.

Also if you thinking that most applications can be non rooted using a shellscript is hilarious. Do you know about prefixification? Apparently not.

Don't talk shit. Get a job. Learn some sense.


Re:A solution in search of a problem

Posted by: Anonymous Coward on February 14, 2007 12:54 AM
You are right, installing a package is a piece of cake. If you have a package for your distribution.
As a developer for I can't provide packages for every distribution out there. Sorry, but I do it in my spare time. Providing source only is not an option because lots of my our users don't know how to compile them. But I still want their feedback now, not when some disto packagers come arround to build a package. (You almost never get any feedback from packagers, not even when disto users report problems to them). So producing just one binary autopackage gives me much more users than building a binary for one distro. (And less hate mails about preferring distro X or using outdated distro Y.10 instead of Y.10.1) So autopackage helps developers here, the hard thing is not to install a package but to produce one for every distro.



Posted by: Anonymous Coward on February 15, 2007 03:28 AM
Providing better packages has little to do with checkinstall-like tools. I tell that as a maintainer of 150+ packages in ALT Linux.

Michael Shigorin


Not entirely balanced article

Posted by: Anonymous Coward on February 13, 2007 04:43 AM
Autopackage is not the only project in this area - Klik currently offers a different technical approach to the problem: <URL:>. I believe that the lead developer participated in the recent summit on Linux packaging.

I was also surprised to see no links in the article to either this discussion: <URL:<nobr>u<wbr></nobr> topackage-considered-harmful/>, or the original analysis of Autopackage by Joey Hess: <URL:<nobr>a<wbr></nobr> ge_designed_by_monkeys.html/>

Joey Hess is a lead developer of the Debian installer, as well as Alien and debconf. The discussion threads on the Fedora development mailing list regarding Autopackage installing into<nobr> <wbr></nobr>/usr/ follow similar lines.


Klik is not an alternative

Posted by: Anonymous Coward on February 13, 2007 08:27 PM
Klik is certainly an interesting project but it's just another third-party repository different to one provided by the distribution. It provides no solution to the problem: The issue is the attitude of many if not most Linux application project maintainers; their habit of throwing a source code package on some internet server, like other people throw away dirt.

Autopackage tries to provide a solution for application projects who work real hard to become killer applications for the Linux desktop. See, for example, the guys of the Inkscape project. Autopackage tries to make PC enthusiasts lives as simple as possible, encoraging them to tell others about great application available for Linux, and to spread them using burnt CDs that work independely of the Linux distribution.

With Klik, lethargic and careless project maintainers will just continue to hope for some third-party volunteer to provide Klik packages, just as they expect third-party volunteers to provide distribution packages.

There's just one alternative I've seen so far, and that's PBI for PC-BSD: There's a working software directory. Here's a tutorial to make PBIs


Re:Klik is not an alternative

Posted by: Anonymous Coward on February 13, 2007 10:20 PM
There's another alternative I guess you don't know about, which addresses exactly the same issues as AutoPackage and then some: ZeroInstall.<nobr>e<wbr></nobr> d-Installation-Systems/page1/


0install looks interesting but ...

Posted by: Anonymous Coward on February 14, 2007 12:26 AM
Thanks for the hint. I already knew about it. In fact, before Nautilus became a sane file manager I was using Thomas Leonard's Rox. So I really like his work and noted 0install rather early.

Unfortunately, while 0install is indeed a decentralized system, it also has (at least) two problems.

The first is its lack of usability: For example, users are used to klick a web page button to download (or install) an application. 0installs needs some command line magic or a drag'n'drop operation. This is not obvious. Also, if you would like to de-install an application, you are expected to "open the cache". What is this and how do you open it? When you look at its tutorial from a usability point of view, you'll note a lot of stuff that's confusing.

The second problem is its total dependency on the network: I may be mistaken but there seems to be no way to burn a few applications on a CD and give that to your friend. This is an important use case for regions with bad internet access. It's also important for Linux magazine -- their frontcover CDs are rather boring right now. Being able to get software without using the Internet is also important for certain (older) users: They like to be able to go into a real shop and buy the required software without studing technical and complicted web pages.

The usability flaws may be solved but the second issue seems to remain a problem I believe. Thus, I consider 0install to be valueable experiment but it doesn't seem to be a solution to the current mmarketing (ie. distribution) problems of Linux desktop applications.


Re:0install looks interesting but ...

Posted by: Anonymous Coward on February 14, 2007 04:06 AM
"0installs needs some command line magic or a drag'n'drop operation."

The UI is from whatever environment you use. Command-line users type commands, ROX and Xfce users drag-and-drop (because that's how those desktops work).

I'm sure GNOME users could set it up to work when you click in epiphany, for example, if they don't like DnD.

"The second problem is its total dependency on the network: I may be mistaken but there seems to be no way to burn a few applications on a CD and give that to your friend."

The Zero2Bundle application will create a self-contained ROX application directory for a program containing all its libraries (those available through Zero Install anyway), which you can put on a CD:

Even better would be a version that extracted the dependencies back into the cache, so that they could be shared properly. No reason why it shouldn't work.


Re:Klik is not an alternative

Posted by: Anonymous Coward on February 14, 2007 06:37 AM
I think the operative word here is "tries". Autopackage "tries" to provide a solution but implementing the whole thing in shell scripts and stuffing away the metadata all over the place is not the way to go about doing this. Autopackage didn't fail because it was a bad idea, it failed because it was a bad implementation of a mediocre idea.

If you read Joey Hess's post keeping this in mind you will see he actually didn't have a problem with autopackage as such. He was actually seeing about adding support in alien for autopackage (which would allow you to convert them to<nobr> <wbr></nobr>.debs) but got frustrated at the way autopackage is built. The fact that he was seeing about adding alien support certainly does mean he didn't reject it out of hand.

It is also interesting to note that autopackage does not require distro support. The distros are actually the last place to look here, because autopackage caters directly to the end user. In the end it was the end user that rejected it. Had it been so good it would have become more popular and people would still be updating their packages. Blaming the distros is just plain wrong since they have got little to do with autopackages' demise.



Posted by: Anonymous Coward on February 13, 2007 06:26 AM
Mike Hearn works at Google, would be cool if Google started to distribute its Linux software with Autopackage.
Maybe the Autopackage project needs to get distributions to start using Autopackage.

Autopackage at Wikipedia;



Posted by: Administrator on February 13, 2007 12:17 PM
Might have actually been a possibility if Hearn hadn't been too busy trying to gut everyone who came before him with a broadsword.

With that said, I have no problem agreeing with the first commenter:
"Autopackage is going nowhere because it's a solution in search of a problem...<nobr> <wbr></nobr>...the reality is that installing packages in Linux is, for the most part, remarkably simple."


Re:I tried it... and it failed.

Posted by: Anonymous Coward on February 13, 2007 10:55 AM
Or even<nobr> <wbr></nobr>./configure && make && checkinstall, which can make a package for your distro (I have used it on Debian and Ubuntu, but also believe it works on Slackware and RPM based systems too). Personally I think it might be cool if there was a Gdebi style wrapper around this, possibly combining alien as well, that way any source tarball or package can be opened by a nice little GUI program to install it in the system's native package format. I know more standardisation would be needed for this (which is why alien is not usually the best solution if source is available) but I think it would be nice.


I agree totally

Posted by: Anonymous Coward on February 13, 2007 11:45 AM
As someone who has written multiple articles on Autopackage and has been following the project for a long time with hope, I think Bruce has written a near-perfect article that's very well balanced.

The problem isn't Autopackage itself, but the clumsy core we deal with and the non-standardisation between distros. I think the first post summed things up perfectly in terms of the blind ignorance from those of us that have been using Linux for years and are stuck in our ways.

I use Debian derived distros, and Debian developers have always been the most actively/religiously opposed to Autopackage, and refuse to see the flaws in the system. I'm not connected to the net myself, and have to rely on source most of the time, because I can't fulfill my dependencies. Even if I were connected, I would still break my dependencies when ever I wanted to try something new.

If I want to try the latest audio player, I shouldn't have to upgrade my entire distro's package tree just to achieve this, it's bloody annoying! I haven't even touched on the fact that every distro has its own interface or method for installing software, it's such a headache for a newbie!

Installing software should be basic, and *uniform*. Linux distros fail this, and we get too caught up in 'zealotry' to see what's staring us in the face.


Re:I agree totally

Posted by: Anonymous Coward on February 13, 2007 02:01 PM
I think the first post summed things up perfectly in terms of the blind ignorance from those of us that have been using Linux for years and are stuck in our ways.

Blind ignorance from experienced users, or blind adherence to the standards set by MS by newbies? Aptitude and/or Synaptic are not hard to manage, but they are different from MS.exe. You do have to set up your repositories, but if it's not done automatically during the install it won't take more than 5 or 10 minutes to do it. And then you have access to 1000's of programs, either from the web repos or the CDs.

If you took a true newbie, someone who had never used MS before and offered them a choice between:

a) you can install anything you find with the click of a button, but you have to find it yourself and there's no guarantee that it won't infect your system with malware. You will very rarely need to install anything from source, which is good because it is really, really difficult to do so in most cases


b) you have to follow a few instructions to set up your system, and then you have immediate access to 1000s of programs from a single, trusted source. You may, on rare occasions, need to install something from source. Most of the tools you need to do this are already in place, but you may need to get some help from more experienced users to get it done properly.

do you really think the choice is so clearly in favour of the point and click?


The shortcomings of Aptitude and/or Synaptic

Posted by: Anonymous Coward on February 13, 2007 09:04 PM
Synaptic has many usability flaws. You see, just because Microsoft invented something, it's not bad per se. Maybe they learnt something about the desktop market in their history? That's called experience I guess.

Just look at the most successful open source application today: Firefox! Do you think it could have been that successful if the would have waiting for respositories to appear for Windows?

Why is there no respository system for open source Windows applications? Maybe that's because it doesn't make sense? Why bother with the boring package descriptions (and names) written by programmers if you have Internet repositories such as that provide access to over 23,000 applications and projects, including professionally written and useful descriptions, screenshots, user submitted commentaries, ratings, and other means to find the best tool?

So your first error is considering Synaptic to be usable. The basic flaw is mentioned by the article: "... unless you know what package you're looking for, basically all our package interfaces are useless."

Your second error is comparing Point'n'Click with APT Frontends based on the current Linux landscape. However, many people want proprietary applications. These application provide solutions to problems no volunteer hacker finds interesting to work at. Will Synptic scale when there will be 23.000 additional proprietary packages included?

Your third error is to assume that repositories protect from installing malware: It doesn't! Because you can as well talk people into using some third-party repository full of malware, just like you can talk any newbie into using a non-offical respoitory full with mp3 codecs and other inofficial stuff. You just need to make them think, it's the only way to get a solution to their problems.

Your next error is the implicit assumption that point'n'click cannot co-exist with package repository. Let's face it: Package repositories are great for server systems and for system software, in general. They just fail to work on the desktop application market.

We should use the best tool for the job: And for the desktop applications, installers such as Autopackage are the best tool for the job.


Re:The shortcomings of Aptitude and/or Synaptic

Posted by: Anonymous Coward on February 14, 2007 11:44 AM
finally, someone looked outside of the square! i'm gonna post something a bit more comprehensive in the parent thread


tried that too

Posted by: Anonymous Coward on February 13, 2007 04:19 PM
Oooooh, I know what you're talking about!! Manually installing packages and keeping the Debian package manager happy is a total nightmare, especially if you have a couple of libraries or applications compiled yourself!

The problem is first that APT thinks it is shifter than it actually is. It always wants to remove half of all installed packages just because one Debian pseudo dependency isn't matched - this even though the "broken" package works perfectly fine.
The real problem here however is, that compile time sub version numbers are treated as holy wisdom. In reality a "" works fine, even though the dependency says "libc-2.3.6-22-dfsg2.90". DPKG and APT just can't know that. Allthough general Linux project version and GNU release incompatibilites are to blame here, the idiosyncrasy of Debians packaging policies and overall lack of cross-distribution compatibility/agreements stall the plattform.

Debian should overcome its "clean-dependency" approach. Because package-version dependencies don't hold up to reality. And a little package naming or splitting standardization with other distros wouldn't hurt too.


so you are newbie, right?

Posted by: Anonymous Coward on February 15, 2007 03:40 AM
n00bs have nothing to do with 1337 messing-a "latest multimedia sources".

Seriously, if you're arguing *for* source-based installs in area where inter-library dependencies are as serious as in Gnome, then you are failure to us maintainers as a user -- it's plain next to impossible to cope with that without dependency tracking tools, especially regarding sonames.

I've recently tried to backport recent Kino for our stable, and you know what? Gave up on third library, since being able to think systematically has so far earned me both half-decent hardware and half-decent connection at home.

If you would have stopped messing with what Debian folks rightfully "religiously" oppose and took the time to stick to ONE half-decent distro (which destroys dummy argument for "different software installation methods" -- which is rather wrong anyways, there are some 5 different ones, two being major -- apt and yum), you would have earned yours instead of complaining for being still a newbie.

> Linux distros fail this
No. It's Linux users who would complain on more competent people and try to reinvent the wheel who fail this, and that.

If you're offline, use stable releases and backports for them. Learn to backport packages. Learn to understand where it's feasible and where the stack change rate is just too high to keep up offline (like basically any video-related stuff).

It should be basic knowledge that free software requires free time, free traffic or just isn't that free. C'est la vie.

Michael Shigorin


Re:I agree totally

Posted by: Administrator on February 13, 2007 10:08 PM
I agree with you. The necessity of autopackage and the lack of momentum behind it is a testament to the low appetite to innovation in the Linux world.


maybe it's just me... but a parallel?

Posted by: Anonymous Coward on February 13, 2007 02:15 PM
Maybe it's just me seeing this, but I took some time to read down through the mailing lists, blog posts, and other background data associated with AutoPackage, and I'm reminded a lot of ReiserFS. Both appear to be great ideas / implementation of ideas in relation to Linux. But, the Primary Maintainers attitude towards everybody else leaves a bitter taste in the mouth.

Now, I don't hold to what Hearn said Linux never making the big improvements, because as far as I can read, he never specified what those big improvements were to him.

The fact is, Apt, as it is now, offers a near complete packaging solution, but it has limits on anything you could do with the package. RPM offers it's own advantages, with ease of distrobution, and being a near-universal standard. Gentoo takes the last point, with the Source-Based packaging method.

Between these three packaging types, there really isn't a need for anybody else to re-invent the wheel (no offense to Klik). As it stands, is it really too much trouble to only expect RPM support from Vendors? RPM's can be converted into<nobr> <wbr></nobr>.debs, and a reliable<nobr> <wbr></nobr>.deb package maintainer should have no problems repacking proper RPM files. I don't think so.

So, my question to Hearn then is, what does he think needs to be done to make these "huge improvements" because I'm honestly not coming up with anything.

As it stands now, Linux, as a desktop OS, is perfectly usable in the form of Mepis Linux, Ubuntu Linux, or PCLinuxOS. If people like Hearn can't deal with that, well...

Perhaps it is a good thing that Autopackage has died.


It just doesn't do what it ought to do

Posted by: Anonymous Coward on February 13, 2007 03:46 PM
Autopackage didn't match up to its goals. It suffers from implementation limitations, dumb ideas.

The original project goal was to provide SELF-CONTAINED Windows-like installers for Linux systems. The project however delivered something in between installers and network setup tools. The generated packages DO NEVER contain a complete application, but always come with dependencies and WITHOUT the required libraries. Whereas Windows-installers always contain the application PLUS any required DLL.

That's why Autpackage installers are unsuitable for installation on Internet-connection-less computers. And if I already have a DSL connection (or modem at least) and the more user-friendly distro package manager, then where is the point in using a half baked and not self-contained installer?

Mimicking Windows installers half-way didn't solve anyones problem. I seriously hope this was the last article and news we heard from Autopackage.


Strawmen argument

Posted by: Anonymous Coward on February 13, 2007 09:52 PM
You critize Autopackage on your personal and additionally false assumption that the "original project goal was to provide SELF-CONTAINED Windows-like installers for Linux systems".

Instead, they may wanted to create a mix of self-contained installer and network setup tools because that seemed the best way to deal with the problems found on the Linux platform. It's not Autopackage's fault if it wouldn't not satisfy your personal requirements.

This is just like criticizing cars because they don't fly.


Re:Strawmen argument

Posted by: Anonymous Coward on February 14, 2007 01:22 PM
it seems the perfect mix to me, if it was purely self-contained, your system would fill up with needless files like windows. autopackage checks that it has what it needs, and lets you install it yourself however your distro sees fit. seems fair to me.


Re:It just doesn't do what it ought to do

Posted by: Anonymous Coward on February 14, 2007 09:57 PM
What's wrong with the Loki installer ? It provide a Windows-style installer experience. I guess if you want to ship a self-contained executable and a nice GUI setup wizard, it's as good as it can get.


Not bad

Posted by: Anonymous Coward on February 13, 2007 03:48 PM
Well it isn't a bad idea but all distros usually have some package systems and they work. So why would they adopt something new? See that on Ubuntu users, they have apt-get/synaptics and it works perfect, so why autopackage? Well maybe for some exotic programs missing in their repositories...
Pixel image editor -


Re:Not bad

Posted by: Anonymous Coward on February 14, 2007 08:30 AM
You make the assumption all disto contain all packages. They don't, that's the problem. So developers and companies making packages have to choose where to spend their resources and which package types they will support. Now factor in changing disto version. Not a pleasant thought.


The problem

Posted by: Anonymous Coward on February 13, 2007 04:34 PM
98% of the people using Linux client-side isn't doing so because they care less about its' technical superiority. They're doing it because they want a free (as in beer) alternative to Windows, and possibly because they're also tired of Microsoft's behaviour as well. These types of people are more conservative than anyone else about changes to the operating system. They want a bland, simple clone of Windows because it's what they already know...but most critically of all, they don't want to have to think...about anything.

These are the same types of sheep that you'll hear complaining about too many distros and too much choice. Again, the reason why they don't want choice is because having to make a choice requires having to actually think, which is the one thing they will willingly crawl naked over broken glass in order to avoid having to do. They want to be as stupid and ignorant as possible, and they're also not using Linux because they want something technically better, as I said...they're using Linux purely because Microsoft's recent behaviour has made it too painful to stay with Windows. Thus however they still will insist on Linux becoming as much an identical clone of Windows as possible.

As the article also said, people who are experienced enough to want to use Linux on the server are also sufficiently experienced with apt that they don't want to use anything else. Autopackage hence doesn't have much of a chance to do anything.

In general, I've come to feel that just about anybody developing Linux these days should concede the market to Ubuntu, and then go and find something genuinely worthwhile to do with their time, because unless you're following the herd, you're not going to get any appreciation either upstream or down. There are a lot of different types of Linux users, but the one thing they all consistently have in common in my experience is that they're generally far too obnoxious to be worth bothering with.


Re:The problem

Posted by: Anonymous Coward on February 13, 2007 09:05 PM
98% comes from where? what studies did you read? the fact is that most Linux users do care about its technical superority.

Those sheep you describe are never going to use a computer without a sheperd around so don't waste your time trying to make it easy enough. And certianly don't try to make Linux feel like windows. Because once you know you're way around Linux feels better than Windows.

I'd like to finish with a quote from Linus, "If you think your users are idiots, only idiots will use it."


Re:The problem

Posted by: Anonymous Coward on February 14, 2007 06:15 PM
I really don't understand anything of what your saying, because your not all that great in expressing yourself. however, I do want to make a point clear, regardless of what you are unsuccessfully trying to say: AutoPackage gives the Linux users the independence to choose whichever distro they like because all packages work for all distros, unlike current package managers. it also decreases workload for developers of a package, because they then only need to create a single installer per platform: 1 for Windows, 1 for Macintosh, 1 for Linux, rather than 1 for Windows, 1 for Macintosh, 10 for Linux.

the reason Autopackage isn't widely adopted isn't because end-users don't like or that distros don't support it, but because developers don't make AutoPackage installers. there isn't a wide enough variety of available software for AutoPachage, so people don't use so there is no demand so the supply doesn't increase and the demand remains the same. however, I see this situation changing by convincing developers of popular software to maintain a single, working, universal, installer for linux. over time more projects would realise this and supply would increase and create a demand which in turn would increase supply and so on. I think all those who like AutoPackage should use only official AutoPackage installers for up-to-date software packages in order to increase demand thus increasing supply.


Re:The problem

Posted by: Administrator on February 14, 2007 08:21 AM
> In general, [...] just about anybody developing Linux these days should concede

> the market to Ubuntu, and then go and find something genuinely worthwhile to do

> with their time

Ok, fine. What do the 80% of the Linux users who aren't using Ubuntu supposed to do?



"Solutions" that make the problem worse

Posted by: Anonymous Coward on February 13, 2007 04:36 PM

Problem: there are too many different installers on the different Linux distros.

Solution: invent yet another one? I don't think so. A real solution would be to persuade the distros using [ rpm, deb,<nobr> <wbr></nobr>... pick one ] to stop using it and all use the same one. But that would be very difficult. So they invent another one, because that's much easier. Of course, the problem now is that where there were N installers, there are now N+1. The problem of persuading everyone to agree on just one, has become harder.


Re:"Solutions" that make the problem worse

Posted by: Anonymous Coward on February 14, 2007 06:23 PM
no, because AutoPackage doesn't care about distros. it works for everyone and installs itself when one first installs software with an AutoPackage installer.

AutoPackage is different from those other Package Managers because it's cross distro and allows full freedom to install whatever you want from whoever you want. complete cross-distro bazaar, without central repositories.


Autopackage is terrible

Posted by: Anonymous Coward on February 13, 2007 10:15 PM
There are real problems with attempting to ship a single binary across multiple distributions. Autopackage tries to sweep these problems under the rug, with name databases, shim libraries, and other "clever" hacks that only make the situation worse.

Binary compatability across Linuxes is hard, and you cannot fix it with one clever installer. Trying to do so is not only foolish but destructive as you make usability worse for those who fall for this snake oil.


Central repositories provides some security?

Posted by: Anonymous Coward on February 14, 2007 05:27 AM
Having a central repository seems like it reduces the chance of downloading malware(especially if all packages are OSS). In theory the packages are checked by multiple people who reject malicious code.

This may be one of the many reasons windows has more malware than Linux (remember much software is installed as root on Linux as well). I can say that much malware has been installed by windows users due to trusting downloads from the vendor.

Note: I have no experience with autopackage but use Gentoo, Ubuntu and Debian package managers often.


Outside the square

Posted by: Anonymous Coward on February 14, 2007 12:00 PM
Albert Einstein once said that you can't resolve new problems with old solutions. Old methods + old technology (repositories) = predictable results. Autopackage tries to shake things up.

The two fundamental flaws of repositories are:
1) All of the applications come from one place, one authority, one authority who dictates what you can and can't install. What if the program you want isn't in the archive?

2) You have to know what you want to install in the first place!

It's not that people are looking for Windows like installer that has all the binaries with it, they want to install *external* applications of their choice (Autopackage at least looks for dependencies, keeping nerds happy and not flooding the system with the same files over and over, unlike Windows installers)! How could someone ever realistically sell boxed CDs if there is no standard for *external* applications.

I don't want my applications to come from a central authority - partly because they NEVER HAVE WHAT I WANT! I want to be able to install what I want, whenever I want, I want choice! Repositories strip choice, choice - which is the main point of OSS to begin with.

Autopackage does three main things:
1) Installs an external application, regardless of the distro, a neutral approach.

2) Checks the dependencies, but lets you resolve them with your own system.... rather like a game requiring the latest Direct X but not coming with it....

3) Places them in a registry with an "Add/Remove Programs" like interface to keep track of what you've installed.

It may not be perfect, but finally someone looked outside the square.

External people, external!


There is nothing outside the square

Posted by: Anonymous Coward on February 15, 2007 06:26 PM
Autopackage is strugling since it looks like another attempt to turn Linux into Windows, which cannot be done for very fundamental reasons.

The goal of autopackage is to alow dumb user to install any software on any distro. This cannot be done since currently Linux is mainly for FOSS and FOSS is a cooperative effort. If one cannot compile or write scripts, he or she is out of the development. Since software duplication is free, such person still can get for free what others have made, but cannot demand anything.

Different community based distros are different because the communities want different things. In particular, I followed the link to the Gentoo guide and found that Autopackage is indeed unusable with Gentoo for very good reasons. It is not an oppinion, it is a fact. I find it funny that Autopackage people started to solve a problem that only commercial distros and closed source vendors have.

BTW, closed source vendors do not have problems delivering to community based distros, just look at nVidia.

Commercial distributions vendors understand the problem and are solving it. Look at the recent Canonnical and Linspire deal.

The problem Autopackage has is that it is not a part of the solution. But who cares?


ABI Changes

Posted by: Anonymous Coward on February 17, 2007 04:49 AM
The vision of a single binary package that will install on any Linux system is a noble one.

Unfortunately, revisions to the C++ ABI, some of them bugfixes, do not help: separate C++ binaries must be packaged for each version of the ABI. That means more development work, in separate environments, and fatter packages. What a pity.


I tried it... and it failed.

Posted by: Administrator on February 13, 2007 06:13 AM
At first I was all-excited about autopackage. It seemed (or presented itself) to be a solution for incompatibilities between systems. But the way it confined its installation to user's home directory and some problems it caused afterwards (which I can't remember any more - as I quickly forget unpleasant things) made me think, that<nobr> <wbr></nobr>./configure && make && make install is a far better solution - and the best of them all in fact. So autopackage bid farewell to my disk soon after it arrived. Idea seems good, but the solution is wrong.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya