Autopackage is a concept that is in the process of becoming a reality, a little bit at a time, in the traditional Open Source manner. The idea is to come up with a single software packaging/installation system that will work across all major Linux distributions, and resolve dependencies, too, so that neither developers nor users need to worry about distribution compatibility issues. This is an interview with project leader Mike Hearn, whose (lightly edited) words will give you an excellent idea of how the project started, where it is now, and where it’s going.
NewsForge: How old is the autopackage project now?
Mike: Hmm. Well, I originally started coding it in about July of last year, but I didn’t release it or announce it as an open source project until about mid-September, in fact it was a few weeks after I moved down to where my current job is. So, I’d say about slightly over half a year old.
NewsForge: How many people are working on it now?
Mike: Well, the “core coders” are basically me and Hongli (foobarwidget on irc). Then we have people like Jeremy and Julien who pop up sometimes and give patches, but most of the work gets done by me and FooBarWidget. Obviously there are more people working on portable packaging than just the people in this project… people on the LSB etc.
NewsForge: Why not just modify the Loki installer?
Mike: Well, the Loki installer is a good start, but it only solves a small part of the problem. Loki’s way of producing portable binaries (i.e. executables that’d work on any distro) basically involved building on a hacked-up Red Hat 6 install and statically linking as much as possible. The Loki installer, for instance, doesn’t support dependancy resolution, which is a pretty critical feature to have for most open source projects that can’t just statically link everything. Also, for instance how do you install stuff via SSH with the Loki installer? It’s GUI only. Fine for games, not so great for other stuff.
The Loki installer is pretty easy to use though, which is what we’re aiming for in terms of what the user sees.
NewsForge: Why not do more static linking, especially now that hard drives have gotten cheap?
Mike: That’s a fairly common question, with what is basically a “stock” answer. I might as well repeat it here, in case some of the readers aren’t aware of it….
Basically dynamic linking has several major advantages, besides the reduction in hard disk space used. It also reduces memory consumption, normally far more of a concern if you want a responsive UI. It also makes updates much harder. For instance, take the GTK file selector. That’s been a bone of contention for a long time now in the community. Unfortunately, we won’t be getting a new one until GTK 2.4. By the time GTK 2.4 is released, GNOME 2.4 will already be out and using GTK 2.2, because the release cycles unfortunately aren’t synchronised. Fortunately GTK preserves backwards compatability, so when 2.4 does come out, you can simply drop it in and all your apps will get the new file picker.
That’s one trivial example of how it can benefit the end user. Obviously stuff like security updates becomes much harder when things are statically linked. It also bloats downloads considerably. Hard disks may be cheap, but the majority of the Net still uses dial-up. We’re being pretty careful to keep dialup users in mind when building autopackage.
NewsForge: Good point. Moving on…
How far have you gotten with autopackage at this point?
Mike: Well, we’re chugging along nicely. At the moment we’re mostly working on the boring architectural stuff. We’ve done some GUI mockups, but we’re still a few months away from having a working graphical front end.
We’re doing quite a bit of work “behind the scenes” as well, like talking with the LSB folks, and the glibc crew to resolve a few problems.
NewsForge: Are the LSB people actively helping?
Mike: In terms of donating resources or stuff like that, no. The LSB is pretty essential though if we’re actually going to make portable packages, without it you run into problems with symbol versioning and so on, so they’re helping immensely in an indirect way. The Free Standards Group has also set up a new packaging workgroup in the last few weeks, which I’m subscribed to. Hopefully we can get some good work done there.
NewsForge: So here you are, 18 and rather new to Linux. Why isn’t some old Unix greybeard leading this project?
Mike: Beats me. Are there many greybeards in Linux at all? I think I saw a survey that said the average age for open source hackers was 28, something like that. There are definately more experienced people than me working on stuff like the LSB, glibc etc., which is all important stuff. I think part of the problem is that it’s very easy to get used to compiling from the source, and just dealing with the current situation, even though it’s less than suboptimal, much like I got used to the fact that Qt and GTK programs looked different. Back when I started there weren’t things like bluecurve or geramik, so one of my first ideas was, hey, let’s create a shared theming system.
But I got used to it, it didn’t seem so important anymore. Plus packaging is hard. I’ve met a few people who seem positively scared of it 🙂
NewsForge: Yes, packaging seems to be the Bane of the Linux Programmer — and user.
Mike: I think if it was easy it’d be solved already. It’s not easy 🙂 If I’d known what i was getting into… well, let’s not go there.
NewsForge: Do you think you have the… stamina… to see this through to a usable product?
Mike: Yeah, I hope so. There have been some pretty bleak times, like when I learnt about symbol fixup collisions. I’ve occasionally thought, “I’m stupid, it’s impossible.” But really we came out of that stage, and I think we have a pretty clear idea of what’s needed now, barring any more nasty surprises.
Anyway, I’ve made this my main project. I extricated myself from previous open source projects, which wasn’t easy, being good friends with the maintainers 🙂
So I have plenty of free time to work on it, and lots of motivation to do so. I think we’ll make it.
NewsForge: Do you think other developers will flock to the project as it becomes more mature?
Mike: what do you mean by developers? as in, people hacking on autopackage itself, or developers using it?
NewsForge: Hacking on it.
Mike: Definiitely. It’s already happened to some extent. After we did the 0.2 release we started getting a _lot_ more contributions. Partly that was just publicity from OSNews, but some of those hackers stayed on and are still sending in patches many months later.
At the moment it’s quite hard, as the documentation lags slightly behind CVS (though we work hard on it) and we’re making a lot of low level changes as the code settles, and when we have various GUI front ends to hack on (the fun stuff 😉 I think we’ll get more hackers involved
NewsForge: I notice you’re just now working on dependency resolution — or at least just starting to get it to work. Isn’t that rather the heart of the whole thing?
Mike: It’s certainly a major component, but it’s quite hard to do well. Apt does it pretty well, minus the need to manually add sources. There’s no point doing dependancy resolution if you haven’t done the basics first, like copying files, building the packages etc.
Also, we have a rather unusual approach to dep resolution. It took quite a bit of work to design and lay the groundwork. For instance, we’ve had the skeleton files system in place since the beginning basically, but it’s been redesigned a few times.
NewsForge: So what’s the next stage?
Mike: Well, currently I’m hacking on these architectural issues. That’s pretty boring for the rest of the team, given that so much is changing they can’t really do much. Hopefully that’ll be over soon, and then really it’s a case of adding features. In particular we want to start writing some GUI frontends soon, so we actually have Loki/InstallShield type user interfaces. Hongli is going to be working on one based on GTK 2. Filip wants to do a KDE one, and has made some mockups already.
Then I’ll be working on improving the user interaction system to give these GUIs something useful to do 🙂
NewsForge: Dare we ask about timelines?
Mike: Well, you know the standard answer to that 🙂 A little more helpfully, I’m hoping we’ll have all the basics in place in about a year. That includes a reasonably stable backend, one or more GUI frontends (we already have a terminal front end), the network, and some documentation.
It won’t be 1.0 final, because that implies we’ve frozen the interfaces. It’ll be a few more months after that, I expect, before we freeze. I want to make sure we’re not pissing all over developers after they begin using our product. Unfortunately, it’s hard to tell, because it relies upon other projects and groups.
For instance, for many apps, we’re waiting for the glibc team to implement grouped symbol fixup semantics. That’s pretty important. Without it, some apps will simply instantly segfault on startup. It’s a complicated and subtle feature, so they want to do it themselves, but obviously they won’t make any guarantees about when it’ll be ready.
Category:
- Linux
