Re: Little redesign of package files for 1.3

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

Don't know, maybe they do. I think one of the 0install guys read this
list so he could say for sure.

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

But the bulk of the installation is done with the install script. a
lot of the code that makes autopackage distribution neutral is inside
the installXYZ functions..

Sure, we could replace it with a structured format like XML (that
would *surely* make autopackage enterprisey ;-)
So, instead of:
    installExe bin/myprogram
    installData share/myprogram/*
we'd have
   <binary>bin/myprogram</binary>
   <data>share/myprogram/*</data>

But what would we get, besides the overhead of an xml parser? It'd
still be autopackage support code executing the same bash code...

What we'd loose is the flexibility that many packagers rely on. There
are a lot of packages (including our own) that
use a lot of custom code in the install section.

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

It does? didn't know that.

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

The move-files-instead-of-copy fix sounds reasonable, Not sure about
the other stuff though - we absolutely don't want to break backwards
compatibility.

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

The difference being that with autopackage you actually *can* run the
install scripts as $user, which you can't with rpm and deb :)

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

I thought we did have that information there.. hmm.. maybe you are
right, that logic is probably in the installXYZ functions. (As you
see, I'm also not 100% sure about how it all works inside)

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