Re: Little redesign of package files for 1.3
"Thomas Leonard" <[email protected]>
| Newsgroups | gmane.comp.autopackage.devel |
|---|---|
| Message-ID | <[email protected]> |
2008/5/28 Isak Savo <[email protected]>: >> Furthermore I read this criticism of autopackage: >> http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys/ [...] >> - 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. Well, as Jan mentioned, the Zero Install tools parse the headers to get the offset to the tarball data. So, making that an official part of the format would make publishing .autopackage files in Zero Install feeds more reliable. [...] > 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? Indeed. The .deb and .autopackage formats are almost the same in this regard, so it's odd that Joey complained about it. But is that really what we want in the future? Take an Autopackage program like Stellarium (the link on the site is broken, BTW). Using AppArmor / SELinux / Plash / whatever, we can quite easily say that it should get write access only to ~/.stellarium, and it will run fine if installed using a more-trusted external program (e.g. Zero Install). But if the package includes the installer, it needs write access all over the place, including the ability to change my menus, add things to $PATH, etc. -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected] For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]