Little redesign of package files for 1.3

"Jan Niklas Hasse" <[email protected]>
Newsgroups gmane.comp.autopackage.devel
Message-ID <[email protected]>
Hi everyone!

I thought about 64 bit support. As Isak said, it would need a new major
version because of the new parameter "CpuArchitecture*s*" 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?
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.