Re: Little redesign of package files for 1.3

> > - 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
>
> Sure, that would be possible. Although I'm not sure I see the use case
> really. I'm not gonna do it just to satisfy people like Joey Hess.


What about the zeroinstall team? I'm not sure, but aren't they extracting
autopackages, too?

I also think it would be good for the autopackage support code itself.
Currently a package file needs to be executed to be extracted. If there's a
bug in this code, a new support code couldn't even fix it (at least not in a
good way). So making an autopackage installable without executing any code
of it, does not only help programs like alien, but autopackage itself for
future developments. Here's an example:

Curretly the data payload gets copied to a working directory before the
installation AFAIK. I think that's not a good thing for packages which are
very big. If I download a 1 GB package, i need 4 GB of free space (.package
file, working directory, extraction of the payload, installed files). I'm
not sure about this though. Let's assume we want to improve this situation.
- .package file should not extract data payload into the working directory
-> disadvantage of the current system: This fix would only be in packages
created with the new development code. If the support code would extract the
package (and create the working directory), this can be easily fixed.
- installData should not copy files, but move them
-> disadvantage of the current system: Maybe a package relies on the old
behaviour. It would therefore not be installable with the new support code.
If autopackages would just call a function "installEverything", this
function would take care of it.

It's true: deb files aren't superior, but currently autopackage isn't better
either. For example the .package file can execute code as root, if the user
chooses so (and he normally will, because it's an installation). If the
actual programm would require a root access, it will look more suspicous.

I hope I explained it clear enough, i wasn't always sure about the language.
I also might be wrong about some points, because I've only taken a quick
look over autopackage's internal structure.

> No, we don't put the path info in the payload, since we don't want the
> application to care about where it is installed. It is thanks to this
> that we can allow non-root installs for instance. That is not possible
> with traditional systems (in practice at least, I know there are
> features of rpm and/or deb that can do this theoretically)

But the only thing that differs is the prefix, isn't it? So there could be
path informations like "share/applications".