Hi everyone!

I thought about 64 bit support. As Isak said, it would need a new major version because of the new parameter "CpuArchitectures" in the header.
Furthermore I read this criticism of autopackage: http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys/
Although is definitely not very nice, he does has his points: Autopackage is indeed more like an installer then a "package" which can be easily read by other programs. But I also think it's easy to fix his criticisms:

- no formal design documentation:
-> add a page for this in the trac wiki

- package must be executed to extract its content
-> add skip_lines, meta_size, data_size and compression to the header and document how to use them in the wiki page

- no path info in the payload
-> advise developers to import everything in the right path into their payload. This should be automatically done by "make install $build_root" and "import *". Then there should be a function called "installEverything" which scans the data payload (like the function analyse() in makepackage) and calls the correspondenting (ehm.. right word?) function (e.g. installBinary for files in /usr/bin).

- not a true package format, just a bunch of shell scripts
-> move everything not needed inside the metadata to the support code. The support code should not need to execute the package. A big advantage of this is: If there's a bug inside some meta scripts (like http://trac.autopackage.org/ticket/45) developers don't need to recreate all there package but only users need to download the new version of autopackage. Also autopackages would become smaller.

I'm not sure if you actually discussed this some time ago (I'm reading the mailing list since 2007), I'm sorry if someone has already brought this up.
What do you think?