This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: System Administration

A conversation with the autopackage team

By Samartha Vashishtha on January 17, 2008 (9:00:00 PM)

Share    Print    Comments   

Curtis Knight, Isak Savo, and Taj Morton are the lead maintainers and developers of autopackage, a set of tools designed to let developers build and distribute distribution-neutral installation packages. In this interview, they share their vision of the project and where Linux packaging in general is going.

Linux.com: How and when did the autopackage project begin? What does the current project team look like?

Isak: Autopackage began in 2002, when Mike Hearn decided he wanted to make Linux easier to use. Hongli Lai and Curtis joined the team in the first year, while I joined somewhere around 2004, and so did Taj Morton. The current team is mostly Curtis, Taj, and I, with occasional contributions from other people on the project mailing list. Geographically, we are spread apart. I live in Sweden, Taj on the west coast of the US, and Curtis on the east coast.

LC: Many open source developers work on FOSS projects in their free time. Does that hold true for you as well?

Isak: Yes, I work on autopackage in my spare time. I recently graduated from university with an M.Sc. in Computer Engineering, and am now working in the R&D department of ABB Sweden, where I am a software developer and researcher.

Curtis: Not enough hours in the day for me! I work as a mechanical engineer and support mechanical, electrical, and hydraulic system design focused on the construction equipment industry.

Taj: I am currently in my last year of secondary school.

LC: How would you articulate the major goals of the autopackage project? Was developing a package management framework like the Windows click-click-install systems an objective?

Isak: I don't think our goal ever was to create an InstallShield/MSI for Linux. It is just that the UI for autopackage is simple, familiar, and fairly straightforward to implement. The objective of autopackage is, and has always been, to make software installation on Linux easier.

Besides, I think that the autopackage UI is more user-friendly than the average Windows installer. Mike Hearn, who started the project, had a vision of what software installation will look like in the future.

Curtis: Intuitive use is a goal, but a comparison with other existing installation methods may not be useful. We have a few firsts to our credit. For instance, using a Web browser to initiate an install session was not a popular feature until we rolled it out in autopackage. There are, however, a couple of installation systems using that hook now.

LC: Autopackage makes desktop users' life easier. Does it also have something to offer to system admins and developers?

Isak: Autopackage certainly helps developers, since it lets them create a single package that works for many users. This is especially valuable for developers of smaller projects that do not have the manpower or the community support to create packages for every distribution out there.

Curtis: There are no specific advantages for admins, but we made sure we did not inhibit that use case. If a graphical front end is not available, an admin can run packages remotely by invoking the terminal console front end.

LC: What major projects are now available for download as autopackages? Will we see any significant additions to the list in the near future?

Taj: Inkscape is probably the largest project that uses and supports our project. Most of our users come from smaller projects that aren't distributed or packaged by distributions. By using autopackage, they only need to create one package instead of many for different distributions. Also, they can make it easier for their users to install their software.

Isak: aMSN instant messaging is another big project that uses autopackage. Twenty-five percent of all traffic to autopackage.org originates from aMSN's Web site. Abiword is another major project using autopackage. On the commercial side, we have Xara Extreme as well as a Dutch tax program benefiting from our project.

Curtis: Smart Technologies, which supplies interactive whiteboards, uses autopackage for remote client software delivery.

LC: An article we published last year talks about your project's struggle for acceptance -- in particular, the slow growth in the number of applications available as autopackages. How do you react to that?

Isak: It is a bit sad obviously, and we had hoped we would get better acceptance. Looking back, maybe, we were a bit naive on that front. What keeps us motivated now is the positive feedback we get from the existing user base. This feedback is mostly from users installing packages, but sometimes also from developers providing autopackages of their software.

LC: To a great extent, autopackage aims to address the complexities that the multiplicity of Linux distributions poses to the common user. Do you think that the variety of choice in this case hinders the wider adoption of Linux?

Isak: Maybe, yes. I think the most fundamental issue blocking adoption is simply the fact that Linux is different from Windows. Also, Linux has a history of bad hardware support, and this pain point isn't fully resolved yet. Recent backing by hardware vendors such as Dell and Hewlett-Packard selling computers with Linux pre-installed, as well as the open sourcing of ATI's graphics drivers and specifications, will certainly help in that area.

And, of course, one thing that often shows up as an issue is software installation on Linux. Windows or Macintosh users are used to visiting a Web site, reading about a particular software package and then downloading it without hassles. Through autopackage, we provide that functionality.

Curtis: Autopackage can reduce the complexity of software installation on Linux, but it also has the potential to add to the Linux distribution landscape. Autopackage seeks to share the effort on packaging user-facing software, and can make a new distribution happen quickly. The developers of the flavour-in-making would just need to focus on the core system software, while using autopackages to supply user software. The result will be distributions that are highly focused and quick to create, without compromising on upstream user software.

LC: Do you think Linux has really arrived as a desktop platform? What other issues (besides too many distros) do you think affect the reach of Linux as a desktop OS?

Taj: The biggest issue here is still the lack of a standard Linux platform like a Windows or a Mac OS. A Linux platform is something we have discussed in the past, but never had the development firepower or community support to follow through. By platform, we mean a standard set of libraries with stable ABIs providing a guaranteed set of APIs. Then, application maintainers and independent software vendors (ISV) could simply say, "We rely on Desktop Linux Platform 1.3," and know that with v1.3, all the libraries that their applications need will be available.

To a certain extent, distros provide this platform, but unfortunately, the differences between them (and even the different versions of the same distro) are so great that they keep any "standard platform" from being created. Backward compatibility is crucial for commercial ISVs, but most Linux distros do not guarantee this.

LC: Why was the autopackage project released under the LGPL instead of the GPL?

Isak: I am not a lawyer, and was not with the autopackage project when the licensing decision was taken. I assume that the LGPL was adopted to make sure that non-free software would be able to use the autopackage framework.

Not everything autopackage is under the LGPL. We have licensed the tools that we provide under the GPL, and use the LGPL for the necessary support code that is part of each package. Some code is even released in the public domain, with no copyright claims at all. All this is to give as many developers as possible the opportunity to use autopackage, regardless of their chosen licensing model. However, all through, we do make an effort to ensure that the "freeness" of autopackage is preserved.

LC: Of late, a considerable debate has raged over some security issues surrounding the project. Critics have pointed out that autopackages, much like shar files, are simply executable shell archives, and share similar vulnerabilities. Do you think these concerns are valid?

Isak: It all boils down to trust. Ask yourself why you wouldn't trust a package provided by a software vendor, when at the same time you do trust the actual program provided by that vendor.

What few people seem to realize is that distribution packages such as . deb or .rpm contain shell script code that is executed during installation, and as such, they could also be called executable shell archives. If someone wanted to create a malicious package, it would be equally easy to do so regardless of the end package format. So no, I don't think these concerns are valid.

LC: Also, there have been apprehensions that since autopackages install to the /usr directory by default, they may conflict with a distro's usual way of installing applications, creating problems for support teams in the end.

Isak: Yes, that is one of the key issues we get criticized about. Our goal is to give the best possible integration with the system in question, and that means putting stuff under /usr. Many applications do not work when installed in, say, /usr/local, and we have tried to persuade distributions to change that. There has been recent activity on the mailing list of Damjan Jovanovic, and things may start moving in this direction soon.

Damjan has talked directly with upstream projects like pkg-config and fontconfig, and has been posting updates about his progress on our wiki. If it turns out that distributions will begin to fully support /usr/local, we can start changing the default /usr to avoid conflict.

Curtis: Part of the issue is that other installers do not check before clobbering files. Additionally, you would not necessarily install the same software using two different systems. The main system installer can always reinstall its package in case of problems, so that system software can be restored.

LC: What is your opinion of similar projects like klik and Zero Install?

Taj: Both of these projects address the same problem in different ways. Klik uses an approach similar to AppFolders, which is used by Mac OS. We have discussed the pros and cons of this approach. Klik's packages come from Debian-compiled binaries.

Isak: The upside of converting already existing packages is that you can get a lot of installers really quickly. The downside is that the final binaries have a smaller chance of actually working on user systems, since they have been compiled for a specific distribution. While some may consider this an acceptable tradeoff, others may not.

ZeroInstall is really interesting because it tries to eliminate the actual installation step. The user just decides to run a program; if the system doesn't have it, ZeroInstall automatically downloads and installs it before it is started. I have not tried it so I can't say how well it works, but I like the idea.

LC: What are the open source technologies and platforms that you think will make it big in the coming years? If you were to name one technology that a budding developer should master, what would it be?

Isak: I am not sure if they constitute a technology, but I definitely see integration and communication as key areas. I'm talking about application-to-application communication (through DBus, for instance), as well as application-to-Web communication (integration with Web applications).

Taj: Again, although it is not really a technology, I think that new developers should learn about the importance of keeping their library APIs and ABIs stable. Another key thing is changing the developer mindset that distros compile software. It is the software maintainers who are the most knowledgeable about how their software should be compiled and built, so they should be handling the packaging bit.

LC: Where do you see the autopackage project heading two years down the line?

Taj: I hope to see acceptance for autopackage grow, both in terms of the number of projects using it for distribution, as well as the distros recognizing it. Also, I hope that in two years' time autopackage will see much more commercial usage from companies, as they port their applications to Linux and need an easy-to-use method of having their applications deployed.

As far as Linux in general is concerned, I would like to see much more focus on compatibility between distros and libraries. This would definitely help Linux gain a footing in the desktop space by providing a stable platform for which programmers and companies can develop applications.

Isak: I absolutely share Taj's hopes, but realistically speaking, I doubt we'll see any support or endorsements from major distributions. Personally, I've begun focusing on making autopackage easier to use for new developers. I hope to do this by improving the tools that are used to create autopackages. My vision is to have a complete GUI where everything pertaining to packaging can be done. I've also thought along the lines of integrating package creation into existing IDEs, such as Anjuta, KDevelop, and Monodevelop. However, all these are just loose ideas as of now.

Curtis: As packaging and integration become more standardized, I see autopackage being updated to use those standard calls. This is already happening with xdg-utils and XDG_* environment variables being included in all recent distribution updates. I would look for new software, either community or commercial, that has not existed on Linux to be rolled out first as autopackages.

Overall, the issues of distributing binary executables -- for instance, symbol management, library sonames to API versioning, and removing application prefixing -- have been shown to be useful to packagers. Certain features from system installers, such as package searching and update, are on the anvil as well.

Hopefully, these ideas will help the Linux platform to surge forward, even if autopackage does not win as wide an acceptance as we hope it will.

Samartha Vashishtha is a poet, intermittent journalist, and Linux enthusiast. He works on the technical communication team of a leading IT company in India.

Share    Print    Comments   

Comments

on A conversation with the autopackage team

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

Misguided

Posted by: Anonymous [ip: 199.164.56.5] on January 17, 2008 10:34 PM
So the answer to the multiplicity of package managers is to add yet another one?

The first problem with this entire area of discussion is it assumes that the end all of 'improving' the situation is to cater to noobs who only know Windows. The biggest benefit of using OSS is the source. Any knowledgable Linux user is comfortable with that, and it *should* work on any distro. The last thing I need is a package system that thinks everyone is a noob, makes decisions for me and hampers my ability to administer and maintain my system the way I see fit.

I tried to try autopackage... since it was provided by Inkscape, but that rapidly turned into one of the most aggravating experience of recent memory. I eventually just got the Inkscape source and built it myself. I now avoid autopackage like the plague.

#

What's wrong with .tar.bz2?

Posted by: Anonymous [ip: 169.233.25.12] on January 17, 2008 11:08 PM
Seriously? Why do we even need these complex binary formats for packages? Why can't we have simple, human-style packages?

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 97.87.136.5] on January 17, 2008 11:10 PM
"So the answer to the multiplicity of package managers is to add yet another one?"

Yes, especially since it's a management tool that can scan your hard drive instead of a database to ensure that your system is truly compatible with the software being installed. What if you want a normal user running a certain program, and only that normal user? That would make things much simpler for businesses who want a simple alternative to Microsoft-based solutions.

--Thomas Holbrook II

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 66.81.38.93] on January 18, 2008 02:45 AM
I already have a tool to determine compatability. It's called ./configure, executed by an admin who knows what he's doing.

A normal user running a certain program, and only that user, is a group/permission issue, not a package installation issue. So called 'simple' alternatives to Microsoft based ineptitude simply result in Linux ineptitude.

#

Re(1): A conversation with the autopackage team

Posted by: Anonymous [ip: 89.244.183.32] on January 18, 2008 05:02 PM
So you got a admin who knows what he's doing. Then you are probably not the target audience for autopackage.
The average home user does not. We use AP to provide binaries to them. Much less work than building one for
every distibution out there. Sure I could tell them "wait some package to adopt it", but then I'd never get any feedback
from my users for current release.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 217.120.8.142] on January 17, 2008 11:42 PM
I could only wish this was widely accepted by all linux distrobutions.. but i think they are to stubborn (is that the right word?) to accept this simple logic way of installing software. They see no problem in packaging each software piece 10 times for each distrobution. They dont see the waste of time in this. They dont see how this will not even be managable if linux was ever to become a popular desktop. Basicly i think its a problem of ego's here...instead of technical.

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 89.244.183.32] on January 18, 2008 06:25 PM
I got the feeling that lots of package builders fear to lose their importance in the community.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 199.120.131.89] on January 18, 2008 12:35 AM
All I know is that autopackage breaks a Debian system.
(Also it breaks RPM systems)
If the only format for a program is is autopackage, I won't use it.

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 89.244.183.32] on January 18, 2008 05:20 PM
Strange, it work fine on my debian box. Maybe it is because I don't tell autopackage my root password.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 202.89.180.231] on January 18, 2008 01:00 AM
Thank goodness, you guys are still alive! And not one ignorant, over-zealous Debian developer has flamed here yet, brilliant!
I wrote an article that's not been published yet which in part mentioned that I was mourning the loss of autopackage, I guess I'll have to put in an addendum to say it's still alive. At the time, Mike had disappeared, there were a few "Autopackage is dead" articles floating around, and the autopackage site didn't come up, so I thought it was a pretty safe bet it had died! But no, you're here, lovely! My favourite project and cause, stick at it lads, maybe some projects like MPlayer would make for packages that will win over people's hearts....

Cheers!
John Knight

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 202.89.180.231] on January 18, 2008 01:03 AM
Ah, I stand corrected, that last post came while I was typing that. It never broke my Debian system....

#

A problem of critical mass.

Posted by: Anonymous [ip: 71.34.91.104] on January 18, 2008 08:16 AM
Autopackage is having a chicken and egg problem. No one creates autopackages because no users uses it. No one uses it because there is a limited number of autopackages. They're hoping upstream devs will make autopackages for their own software but there isn't enough users to make it worthwhile.

The autopackage devs need to kickstart this cycle and reach critical mass faster. Based on the interview, they're hoping this kickstart will be on the demand (user) side by distros supporting them. I don't see this happening. The distros have nothing to gain but added support costs due to two installation mechanisms.

I feel a better solution is the supply (package) side. They need to start packaging autopackages themselves. Provide an easy infrastructure to maintain/update those packages. Perhaps they could use GoboLinux (already abstracted dir paths) or pkgsrc (very portable) or arch (AUR is nice for maintaining). Once there is a reasonable supply of packages there will be interest on the user side. I doubt the supply side will come for the commercial world. They only react to demand.

#

Re: A problem of critical mass.

Posted by: Anonymous [ip: 202.89.180.231] on January 18, 2008 03:00 PM
I concur.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 89.1.63.105] on January 18, 2008 09:35 AM
A good use for autopackage could be to provide hardware drivers that are not present in the kernel, maybe the hardware vendors can be interested.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 82.137.218.227] on January 18, 2008 02:25 PM
The Desktop Linux will never happen....hahaha

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 62.56.123.252] on January 18, 2008 07:32 PM
"ZeroInstall is really interesting because it tries to eliminate the actual installation step. The user just decides to run a program; if the system doesn't have it, ZeroInstall automatically downloads and installs it before it is started. I have not tried it so I can't say how well it works, but I like the idea."

If you're on Ubuntu, type these two commands (sorry about the formatting):

$ sudo apt-get install zeroinstall-injector
$ 0launch http://rox.sourceforge.net/2005/interfaces/Edit

Congratulations; you've now tried it! If you want to get rid of it:

$ sudo apt-get remove zeroinstall-injector

If you want to get rid of all the files it created when running Edit:

$ rm -rf ~/.config/0install.net ~/.cache/0install.net

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 76.74.192.89] on January 18, 2008 07:40 PM
I really like autopackage. They're easy to install, and don't give headaches to developers. Really looking for more wide-spread usage of it.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 122.164.226.195] on January 18, 2008 07:48 PM
You know what would help? A distro with lots of autopackages. That way it can be a demonstration thing. Personally, I've grown to love repositories too much and I haven't used autopackage since.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 189.193.58.254] on January 18, 2008 10:23 PM
go autopackage! i think you need to talk to more crossplatform upstream desktop projects like mplayer, vlc, opera, pidgin... go for the big ones and the small will fall :D

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 210.0.106.26] on January 19, 2008 05:02 AM
It's a pity that Autopackages are still a bit fiddly to create. Debian packages are a POP to create by comparison. (especially if you just use Checkinstall, which I don't do when I'm going to distribute the packages). I haven't used many Autopackages - just Warzone 2000 and Scribus, but it didn't cause any damage.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 80.30.33.158] on January 19, 2008 11:00 AM
Glad to see that there are people on the Linux community with a head over their shoulders. Linux does need to become a platform, or will be forever irrelevant on the desktop. Sadly, this thought does not seem to be wildly supported.

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 216.99.102.28] on January 21, 2008 04:37 AM
This is not going to work, a dream.
The basic concept has merit, but this is running in the wrong direction.

Linux is a moving target, constant rolling development, it's the nature of the beast, APIs are not going to be static, stuff will break, it's not windows or mac where thing remain static for long periods of time.
Baring the availability of native binary packages well scripted source compilation is probably the best route, a standardized front end something module-assistant like maybe.
Alien may be an alternative for non-native packages in some cases that type of thing may be another direction.

BTW allowing users to install apps to /usr will not happen on my boxes.

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 89.244.189.18] on January 21, 2008 09:24 PM
Same here. /usr is managed by the distro. Everything else goes to /usr/local. Autopackages can be installed to the user's home directory. So no conflict here.

#

Re: A conversation with the autopackage team

Posted by: Anonymous [ip: 202.89.180.231] on January 23, 2008 01:14 AM
Only root can install to /usr

#

A conversation with the autopackage team

Posted by: Anonymous [ip: 189.0.75.164] on February 09, 2008 04:39 AM
Who never had a "./configure, $make, $make install" problem? For geeks Autopackage is one thing more. For newbies, like me and so much others, is "The Solution 1.0". Here in Brazil, we have Volkswagens and Fiats (also a lot more, of course). Think that:
It rains. Who has a Volks and becomes a Fiat user probably will break glass cleaner switch. It's on the same side of Volks cars but rotates on the contrary way. Equals in form and in function. The second thing the user can do - if the switch is ok yet - is turn on the back cleaner. And the rain goes on and on...
This is the real problem with Linux users coming from Windows. One says: "This icon must be the intaller and ... click-click...POOF! Hi Freeze!" Ok, Linux doesn't make POOF! when I make mistakes (I got freeze sometimes...).
No problem who starts learning Linux. The most uses Windows and there are a big difficulty to change the OS. Terms, words, concepts, almost everything is different. Ok, Linux is not Windows, and I think that both are good, but different. The World needs buttons because time is money.
I think that Linux programers must look at about what the beggining users will think when choose install a driver, for example.
Who never said (or thought): "What the hell means 'No such target or directory'? I didn't ask nothing like this! I just want to install my wireless driver!!"
Linux is powerful, but one needs to be powerful to understand it at the first seeing. How many Linux foruns starts with "PLEASE! HELP ME TO INSTALL A DRIVER!"?
How many years past since Microsoft released Windows 3.1 with DOS and autoexec/config.sys-configure-boot.bat? We want to learn Linux with no breaking keyboards way of life. Congratulations to the Autopackage team. Thanks.
PS: I haven't got to install my wireless driver rt2561etc with ./configure #make #make install - still now and to use internet I had to write everything. I think that's not a good idea in this timeless World.
Just one thing: Imagine you paying something in your bank and the attendant says: "Wait a minute please! I need to write some codelines at the Bankux edition to configure your new payment file and... I do a ./configure here... and $make here... and $make install here and - Voalá! Ready? Could you turn back next Monday while computer builds everyth... Where are you? Hello-o!" You've been gone.

#

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



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya