Autopackaging amaroK

I remember first hearing about Autopackage 2-3 years ago and it struck a note with me. At the time I was new to Linux and hated RPMs and never had much luck with autotools (not much has changed with the latter or the former really ) So the idea of Windows-style installers was brilliant! I tried to get involved with the project but I rapidly came to realise I didn’t have a clue when it came to all the important stuff I needed to know.

With time comes understanding, and now I realise autopackage isn’t great because of the graphical installers. Many other projects have proved you can bundle a graphical installer, that compiles from source or provides a binary that is built in a “distro-neutral” fashion. I find their technology exciting, and I hope it will reduce the amount of time we have to spend helping people who are new to Linux getting amaroK installed.

amaroK could probably be autopackaged quite easily. We have 2 certain dependencies, KDElibs and Taglib, and it should be quite simple to make the detection scripts for those. The engines are loaded at runtime, and we can show helpful failure messages, like “Install xine-lib!” (well almost helpful). The biggest problem is our use of the STL. libstdc++ has no binary compatability (unlike KDE and Qt). So we have to basically build an autopackage for each GCC version (ouch), or remove as much STL dependence as we dare. Another issue is that most of amaroK has to be installed to a KDE prefix (Autopackage allows packages to be installed anywhere). But, at least at first, I will force installation to kde-config –prefix.

I don’t think I’ll make headway removing STL usage. People like the STL, I even like some parts of it So maybe we can just hope that things like std::vector are binary safe? Maybe.

Still this is an interesting new project I look forward to attempting.