Re: Little redesign of package files for 1.3

On Wed, May 28, 2008 at 1:21 PM, Jan Niklas Hasse <[email protected]> wrote:
> 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.

Indeed.

> 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:

The problem with that post is (among other things) that all the
arguments are based upon the (IMO wrong) assumption that
a) the deb/rpm model of packages is superior
and
b) it is a good thing to be able to convert the package or somehow
"open" it from another program.

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

But we do have documentation. Sure, we could have even more
documentation, especially regarding the design of the system but that
has never been a priority for us. Focus has always been on making
documentation for packagers and end users.

> - 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.

> - 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).

If i understand this argument correctly, then one of our main
advantages are suddenly converted into a argument against autopackage?

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)

> - 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 can somewhat agree with this. But not for the arguments he's using
("It's not a true package format", as if that's a goal in itself), but
rather to make the distinction between *the package* and *autopackage
support code*. The reason you highlighted is a good one for example.

> 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?

It's been discussed, in various forms. Most of the arguments against
autopackage boils down to "it's executable and therefore dangerous"
alternatively "it's not centralized, so how can you trust that the
package is 'safe'".

They both boils down to "who do you trust?" We argue that the
person/team making the package is the same as is writing the actual
program. If you trust the program, why not trust the package? The
autopackage parts are available on our svn repository and is 100% open
source (with a few pieces of code in the public domain).
As far as the 'autopackages contains executable code' argument is
concerned, well so does your average .deb and .rpm...

The centralized vs decentralized argument is more a matter of religion
than actual facts, but the recent debian ssh security bug should at
least show that the centralized distribution model isn't really a
solution. In addition, few (none?) distributions actually scan all the
software in their repositories for "evil" code before they are
distributed. (Plus the discussion about "what is evil code". Mike has
discussed this on his blog (http://mikehearn.wordpress.com). He's a
clever guy, and its worth a read.)

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]