Linked by Mike Hearn on Wed 3rd Sep 2003 21:10 UTC
Linux I wrote an article a while ago on Linux packaging and Autopackage. There seemed to be quite a lot of interest in it so we got version 0.3 released today.
Permalink for comment
To read all comments associated with this story, please click here.
Some answers
by Mike Hearn on Thu 4th Sep 2003 11:53 UTC

Hi,

It's good to read about peoples successes with the software. Here are some answers to your questions:

* Perhaps you should write integration parts with popular package management systems...

We intend to have integration with at least RPM and maybe DPKG and portage in the future. Integration in this context means:

* We will register software installed via autopackage with the system database using either the generic short name of the package, or if specified a name specific to a distro (so if a popular repository chooses a certain name for a program you can still interop to some extent). That means you can use RPMs query file, list files, and remove functionality, and other RPMs that depend on that package should (cross fingers) still work.

* We will attempt to locate distro specific packages off the net to install dependencies where possible, rather than other autopackages. On systems like Debian and Gentoo, that means integration with apt/emerge and so on. On systems like Red Hat, it'll probably mean bypassing yum/apt and going direct to a repository and downloading the files ourselves.

This code hasn't been written yet though. Volunteers needed.

* In my test, I am not connected to the Internet. Is there a way to install without the need to grab file(s) from Internet?

At the moment you have to "hack" around it. There are lots of little things like this we need to polish, which is why it's a 0.3 release, not a 1.0 release ;) Curtis told you how to do it for now though.

You can also download the autopackage core code then use the setup script in there.

* Is there a GUI ... for an Add/Remove programs frontend too, or is it only for installing packages.

There currently is no such GUI. In a future release we will make uninstall and verify output via the frontend protocol, which will mean that once both KDE and GNOME support the actions part of the .desktop spec, you will be able to right click the menu entry/launcher and choose "uninstall" or "verify" and in future "update" too. We may provide an explicit UI for this too, but there are currently higher priorities. Typically we're aiming for tight desktop integration - if you aren't running KDE or GNOME, that means you may still have to use the command line sometime (but you probably don't mind that).

* This is x86 only right? Or can it do others, or even multiple architectures, in one .package?

At the moment we do not have any mechanism for dealing with multiple architectures. The plan is to support "mixins", which are super light weight packages (basically just tarballs in fact) that are downloaded or selected by the Prep scripts and overlayed onto the package payload. That's one way to support multiple architectures (and for instance multiple C++ ABIs) without bloating the main package too much, but requires careful thought.

The other problem is that most people use x86 - at some point I want to research cross compilers and figure out how easy we can make the process, so the same build process can spit out PPC binaries as well. We'd probably draw the line at PPC, I don't know of any other architectures other than x86 and PPC which are popular on the desktop.

We will get to this feature eventually, but volunteers are needed as it's not a high priority right now.

* Are there plans to port this to other ( non linux ) platforms

No, there are no such plans. I don't intend on this being portable outside of Linux, it's hard enough just supporting different Linux distros, other platforms entirely would be insane.

Remember this system is practical because Linux distros are basically binary compatible. Other systems are most certainly not bincompat with Linux (at least not without emulation). Being mostly based on shell scripts, we take advantage of every feature available in the GNU utility set, variations between different versions of the toolset are enough to break us, supporting a different set entirely is out of the question.

* Nice work. BTW, the word is spelled "dependency." I don't get why so many open source projects make the same spelling error.

Where is it spelt incorrectly? I thought I had got rid of all the incorrect variations of this word, but I guess I still use the wrong form by mistake sometimes.

* Ok really wishful thinking but will there be some sort of mass convertor from another package formatter to this?

It's wishful thinking. autopackages are structured very differently to RPMs or DEBs. They must be written from scratch.

The intention is that we'll be able to download and install packages built for your specific distro, so for instance on Debian we would use DEBs to resolve dependencies where possible, but it's not a good idea to try and use DEBs on Mandrake, or vice-versa.

Especially since (correct me if i am wrong), basically rpms debs are a compressed set of files with some additional information right? So such a conversion tool wouldn't have to do that much work would it?

That's what all packages are, basically ;) The key is in the contents and structure of the additional information.

Also when his thing is ready is there any way to get this pushed as a standard packager like in LSB compliance?

autopackage is not suitable for standardisation, it's very complex and I can't imagine anybody wanting to implement their own version of this. If we do our job well, popularity will take care of standardisation.

* Looked at EPM?

Yes, we're aware of that project, our goals are somewhat different. EPM generates packages specific to each form of UNIX they target, as well as simplistic self extracting packages. We are focussed purely on Linux, and making the packages integrate well with that platform, rather than portability.

* What is the difference between autopackage and something like redcarpet?

Red Carpet works by having Ximian choose software, then building packages for each distro they support separately. They do not support Mandrake for instance, nor Debian. We try and support almost every distro (or to be more accurate, we adapt to distro oddities as we find them, as most distros are largely compatible). Under the hood, they work very differently - for starters anybody can make an autopackage, whereas to get on Red Carpet you must talk to Ximian.

I hope that helps
thanks -mike