GStreamer Conference 2013, 22-23 Oct, Edinburgh

GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.

Create an account

Subscribe to LWN

Return to the Front page

Shumway lands in Firefox

LWN.net Weekly Edition for October 3, 2013

Integrity and embedded devices

NUMA scheduling progress

LWN.net Weekly Edition for September 26, 2013

Printable page

Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Autopackage 1.0

March 30, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

The Autopackage project hit 1.0 on March 26th. Autopackage is a "multi-distribution binary packaging framework for Linux systems." To put that in layman's terms, Autopackage is something like an InstallShield application for Linux users.

Autopackage is not an attempt to replace native package management -- it doesn't replace RPM, dpkg or any other system of package management for Linux distributions. Instead, Autopackage is designed as a packaging system for projects and vendors that wish to ship applications for multiple Linux distributions without having to make packages for every variant of every distribution they wish to support.

The Autopackage system is primarily designed for use with packages for desktop users, like Abiword, Inkscape, Gaim and others. The default front-end for Autopackage uses Gtk2, but there is a a Qt frontend available as well. It's worth noting that Autopackage is licensed under the Lesser General Public License (LGPL), which makes it suitable for free software and open source projects as well as proprietary software. The package format itself is a gzipped tarball with a "stub script" at the beginning of the file. It is, in other words, a sort of executable, self-extracting archive format.

We tested a couple of Autopackage .package files on SUSE Linux 9.2 and the Ubuntu Hoary Hedgehog pre-release. For the most part, we were pleased with its operation. Autopackage is simple to use, and works from the command line or using one of Autopackage's GUI interfaces. When a user finds an application packaged with Autopackage, all they need to do is download the .package file and run it. The first time a .package file is installed on a system, it will search to see if Autopackage is installed. If not, it will download Autopackage from and install it, then proceed with the installation of the selected package.

The first package we tried to install was Abiword, which is available from the Autopackage downloads page or directly from Abisource. We first tried to install Abiword on an Ubuntu Linux system. Unfortunately, Autopackage complained that it failed to find the "enchant" spelling checker, even though it was installed on the system in /usr/bin. We had better results with the Abiword package on SUSE Linux, however, and were able to install that package with no problems.

We tried the Autopackage for Inkscape next on Ubuntu, and found that it installed with no problems. We also tried removing the packages and re-installing them to see if there were any glitches or unwanted side-effects. The Autopackage system handled removing and re-installing the package just fine. We even used Autopackage to uninstall itself, and were able to do so without any problems. Overall, we were pleased with the operation of Autopackage.

Autopackage does have a number of limitations, however. First, it's limited to x86 systems. Third parties that want to package applications for Linux on other architectures will not be able to use Autopackage, at least for the time being.

The Autopackage system also does not integrate with the system's package management. This means that RPM or dpkg will not "know" about the existence of an application or libraries installed via a .package file. For some packages, this may not pose a significant problem. For example, if a user wished to install the Linux version of Yahoo! Messenger, it's unlikely they'd have other packages that depend on it or any need to manage the package via RPM or dpkg.

Another drawback for Autopackage is the lack of support for package signatures. The Autopackage FAQ discusses the rationale for this. Since Autopackage is not a centralized source for software, unlike Red Hat, it creates some complications for package signing.

Finally, since Autopackage depends on a working Network connection, it could pose a minor headache for users on dial-up who download their first Autopackage and then try to install the software when not connected to the Internet.

We didn't actually try creating any Autopackage packages, but from the documentation, it doesn't seem that creating an Autopackage is much more difficult than creating RPM or Debian packages.

The project is now working on bugfix releases in the 1.0.x series, and development towards the 1.2 release. The project TODO list provides an indication of where Autopackage is headed for future development.

The Autopackage team has a Flash installation demo and 4-step tutorial that show how easy it is to use Autopackage.

Overall, Autopackage is a very promising project. It makes it possible for third-parties to distribute software for Linux users without the need to create sets of RPMs and Debian packages suitable for many different Linux distributions. It's also easy to use, and should require little skill for users to manage. It's too bad that such a system is still necessary at this time, but it fills a necessary gap until the day that Linux distributions can settle on a standard base system and packaging format.

(Log in to post comments)

Autopackage 1.0

Posted Mar 31, 2005 5:13 UTC (Thu) by jwb (guest, #15467) [Link]

The problem with Autopackage seems social instead of technical. It encourage the behavior, common among users of other major operating systems, of finding random byte strings on the Internet, and running them through the CPU. When you install a package from the Debian archive, you are taking advantage of an editorial process that endeavors to make certain the packages can be safely installed and used. Furthermore Autopackage provides no mechanism for updating software, which is a far more difficult problem already addressed by apt and the others. Providing a means to install software but no means to apply security updates borders on negligence. Downloading and installing nonupdateable packages (RPM, deb, or Autopackage) from unknown sources is not a smart behavior and I hope it doesn't become the normal way of installing software on Linux systems.

Autopackage also doesn't seem to solve technical problems for anybody except proprietary software vendors. And honestly, who gives a flip about helping those guys out?

Autopackage 1.0

Posted Mar 31, 2005 8:29 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

First, the habit to download applications from other places than the
distribution-sanctioned ones is also widespread in Linux, so there's no
need to be snotty about it. There are countless website hosted by
sourceforges that offer a range of rpms and debs...

And it's not just proprietory software vendors who don't like to create an
rpm for every distribution under the sun; Autopackage also solved my
problem very neatly. I'm the maintainer of Krita and I wanted to make
available a binary of Krita for people to test. Telling people to use a
source package was no option, because the source package of Krita includes
KOffice, and installing a KOffice cvs might hurt their existing
installation of their productivity tools.

So I used apbuild to build a binary, with ImageMagick and lcms statically
linked and made that binary available from my homepage. For a lot of
people it just worked -- I've had success on SuSE 9.1 and 9.2, Ubuntu
Warty, Fedora Core 3 and Peanut Linux. I didn't go the whole hog of
creating a complete autopackage, mainly because I didn't have the time to
figure it out, but for the bimonthly releases of Krita we are planning
after the KOffice 1.4 release in June 14 I am certainly considering
autopackages. I simply don't want to have to create debs and rpms and what
not for all the distributions out there.

Autopackage 1.0

Posted Mar 31, 2005 12:33 UTC (Thu) by arafel (subscriber, #18557) [Link]

for the bimonthly releases of Krita we are planning after the KOffice 1.4 release in June 14 I am certainly considering autopackages.

You're obviously free to do that, but you should understand that it will almost certainly reduce the number of people actually using your releases.

Until AP actually works with whatever package management is in use on the machine it's being installed on, it should be avoided like the plague. I *really* don't need something else playing around with libraries and stuff behind dpkg's back.

Autopackage 1.0

Posted Mar 31, 2005 13:17 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

Reduce? Compared to having no binaries available? Are you serious? Of
course, if you are volunteering to make available debs and rpms for SuSE,
Mandrake and Fedora Core for me, I might reconsider. But otherwise I'll
choose the only practical way: create one binary that peope can install in
their $HOME and play with.

Autopackage 1.0

Posted Apr 1, 2005 15:03 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

What happens when the user will want to use a newer version of Krita that will be eventually availble through the packages management system?

How do you upgrade an installation?

If there's a buffer overflow in ImageMagick that is fixed through the standard security updates of the distro, will it update with your Krita package?

Autopackage 1.0

Posted Apr 5, 2005 11:53 UTC (Tue) by ranger (guest, #6415) [Link]

Of course, if you are volunteering to make available debs and rpms for SuSE, Mandrake and Fedora Core for me, I might reconsider.

By the time you release, I hope to have a solution for all current versions of Mandrakelinux (based on automated rebuilding from cooker). Dag may do it for you on Fedora, don't know about SuSE.

But otherwise I'll choose the only practical way: create one binary that peope can install in their $HOME and play with.

But, it won't work:

If your software uses QT/kdelibs, or just relies on large C++ libraries, then you must be careful. This is because of C++ Application Binary Interface (ABI) issues: GCC 3.4 broke C++ ABI (again), so software compiled with GCC 3.4 can mysteriously crash on GCC 3.2/3.3 systems, and vice versa. Because of this, we cannot guarantee that your software will run on all systems. At the time of writing, most distributions still use GCC 3.2, but GCC 3.4 distributions are coming and GCC 3.2 distributions are not going to disappear any time soon.

So, your "one binary the peope can install" probably won't run on both Mandrakelinux 10.1 (KDE built with gcc-3.3) and Mandrakelinux 10.2/2005 (KDE built with gcc-3.4). And, if it works for 10.1, if the user upgrades to 10.2, it will be broken by the upgrade too. A solution based on rebuilding from SRPM will prevent the first issue, and using an automatically generated distribution-specific release tag in the RPM solves the second.

Autopackage 1.0

Posted Apr 10, 2005 21:50 UTC (Sun) by FooBarWidget (guest, #10500) [Link]

We have some ideas for working around even this problem. It involves compiling multiple versions of the same binary, and ship package binaries with different ABIs. During install time, autopackage can autodetect which binaries it should install. To save space, we could use something like xdelta if the difference between binaries are small enough. I might start working on it next week.

Autopackage 1.0

Posted Mar 31, 2005 7:13 UTC (Thu) by dmantione (guest, #4640) [Link]

The whole story reminds me about Loki Setup. How does it compare?

Autopackage 1.0

Posted Mar 31, 2005 15:55 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

That's exactly what I was thinking, and was about to ask... This sounds
like they swiped the idea straight from Loki Setup (though, I see no mention
of such inspiration anywhere on their homepage), and I'm at a loss to see
what it adds that Loki Setup doesn't already give you... Does anyone know??

Loki Setup URLs, for those not familiar:

http://www.lokigames.com/development/setup.php3
http://www.icculus.org/loki_setup/

The LSB standard is RPM

Posted Mar 31, 2005 8:34 UTC (Thu) by astrand (guest, #4908) [Link]

>it fills a necessary gap until the day that Linux distributions can settle on a standard base system and packaging format.

There is a standard packaging format: LSB has standardized RPM3. Installing RPM packages on Debian works great, by using alien. IMHO, an installation GUI should work as a front end to RPM or Alien. We are using this approach with the ThinLinc installation program, and it works great.

Besides, using RPM is a requirement if you want to be RHEL compatible, if I remember correctly.

The LSB standard is RPM

Posted Mar 31, 2005 10:11 UTC (Thu) by khim (subscriber, #9252) [Link]

There's more. This is from discussion on OSNews (answer on this):
Now Mr Hess is coming from the perspective of "how do I make alien support this", and he has discovered that you cannot. Good. That is also by design.
The right way to integrate autopackage with dpkg and rpm is for it to manipulate the systems databases directly, not to try and convert package formats ahead of time.

Translation from English to English: you see - installation of any program in Windows can bring break anything in your system down and make any other totally unrelated program shaky. This game of "russian roulette" is so good that we really should introduce it in Linux - otherwise Windows users will not feel at home. Autopackage makes such russian roulette real in Linux: congratulations.

P.S. Do RPM and DEB formats have protection against "russian roulette" style of work ? To some degree: a lot of work is done by package system and not by pre- and post- install scripts. Yet, there are still possibility of things going astray (but without cooperation there between different distributions it's quite hard to do more) so rigorous testing of distribution maintainers does the rest. Autopackage makes problem worse and simultaneously encourages installation of stuff from around the globe without help of distribution maintainers. To me it looks like clear recipe for disaster.

The LSB standard is RPM

Posted Mar 31, 2005 23:13 UTC (Thu) by dvdeug (subscriber, #10998) [Link]

There is one, and only one program that should be manipulating the package information on Debian: dpkg. It's system-critical information, and I don't want a version of rpm messing with it, much less random packages from the net.

The LSB standard is RPM

Posted Apr 7, 2005 13:11 UTC (Thu) by mikehearn (guest, #29106) [Link]

At least in my experience, distro maintainers hurt as often as they help. I've worked on projects other than autopackage where lots of distro packages have been broken badly, in such a way that we got lots of tech support requests and "bug" reports.

Debian and Gentoo have also both managed to patch, QA and deploy fixes for non-existent security vulnerabilities before.

In other words, I think your assumption that autopackages will be bad compared to distro packages is itself a bad one.

But we'll see. Only time will tell.

Autopackage 1.0

Posted Mar 31, 2005 9:57 UTC (Thu) by khim (subscriber, #9252) [Link]

Autopackage is something like an InstallShield application for Linux users.

Exactly. It's blob of untrusted software to be run with root permissions. Do we really need this ?

In Windows world there are changes to go away from installers like this (MSI packages) - not very efficient and somewhat clumsy, but anyway... So why will we need to introduce such abomination in Linux ?

Think about it: autopackage is tool where installation if "this oh so very cool rainbow calculator" can very well insert troyans in your coreutils package and later (when autopackage will be well-integrated in rpm/deb package systems) it'll be even easy to conceal changes in checksums. Is this really a step forward ? Gosh.

Autopackage 1.0

Posted Mar 31, 2005 10:46 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

So, what you are basically saying is that only distributions should be
allowed to distribute software, ordinary developers of free software
should wait until their project is picked up by packagers?

If anything, autopackage is safer than relying on distribution format
packages because you can install them into your local user account where
they cannot wreak havoc in your system.

Autopackage 1.0

Posted Mar 31, 2005 19:45 UTC (Thu) by khim (subscriber, #9252) [Link]

Where this idea come from ?

Biggest problem with non-distribution install is conflicts between packages from different sources. When you are using distribution packages this problem is mostly absent, but when you are trying to install different packages from different sources you need sandboxing (at the very least any change should be cancellable). And as Windows world showed delegating this cancelability to program creators is "totally bad idea"(tm) - package system should enforce some rules. See Windows Installer for some ideas - it's not great implementation of the idea but it's still better then InstallShit^H^H^H^H^H^HAutopackage.

Autopackage is good old "plug-and-pray" idea: run installation script and hope for the best. If it does not work... you are out of luck: there are few knobs to press and they are not readily available. This is biggest problem with installers in Windows world: if everything works fine, then user is happy. If installer does not work then you are reduced to dances with tambourines - there are no good way to track problems. Any installer can screw you system beyond recognition and there are no way to see what installer will do and there are no way to prevent suck screwups.

Autopackage 1.0

Posted Apr 1, 2005 12:05 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

"Where this idea come from ?"

Well, you know, the everyday practice of being a maintainer of an open
source application who wants to give people a chance at having a go at
his application with minimal effort on his part... I can use apbuild to
create a binary that runs almost anywhere -- and if I package it in
autopackage my users will have nice frontend, too.

Of course, if you're going to forbid me to distribute Krita as an
autopackage, no doubt you're going to help me create proper debs and
rpms', aren't you? My email address is boud@valdyas.org. Thanks in
advance for helping me do the proper thing!

Autopackage 1.0

Posted Apr 2, 2005 20:32 UTC (Sat) by khim (subscriber, #9252) [Link]

Have you really tried to do this ? Autopackage is very unreliable when KDE (or any C++) applications are concerned. It's not a solution, after all - It's band-aid (and poor band-aid). If you want to life in world full of band-aids you can as well switch to Windows.

I never said Autopackage is trying to solve non-existing problem. But it does it so poorly that then end result will be more frustration for users and more problems instead of less.

At least with .deb or .rpm I can find a way to make it work on my Gentoo-based system (did it few times with programs not included in protage). With Autopackage I can not: it installs fine, but in most cases it does not work and there are no hints to show me why.

P.S. Of course I have pretty minimal installation of Gentoo as sacrificial system (everything compiled with gcc 3.4.x, for example): do you really think I'll be comfortable enough to run strange scripts on my work system and/or install lots of unused stuff on my test system ?

Autopackage 1.0

Posted Apr 10, 2005 21:55 UTC (Sun) by FooBarWidget (guest, #10500) [Link]

Bandaids can help speeding up the recovery. If you dismiss all bandaids, and keep aiming for The Perfect Solution(tm), then you will never get work done.

"With Autopackage I can not: it installs fine, but in most cases it does not work and there are no hints to show me why."

Care to explain what exactly the problem is? There are other Gentoo users using autopackages but so far nobody has reported that it does not work. If there's a bug, then it must be fixed.

Autopackage 1.0

Posted Apr 10, 2005 23:32 UTC (Sun) by whocares (guest, #29180) [Link]

Well now i understand thats why there are so many a__h*les in this world.
If you think AutoPackage is sh!t make a BETTER tool. The last thing Linux needs is
YOU doing bad critic!

Autopackage 1.0

Posted Apr 1, 2005 3:37 UTC (Fri) by flewellyn (subscriber, #5047) [Link]

No...distributions should package binaries, and the makers of the software can (if they choose)
package binaries as well, and if the binaries they provide aren't compatible with the distribution,
then the user can go grab a source tarball and do the usual ./configure; make; make install
dance (or, on Gentoo, the emerge dance).

This thing looks like it'd really only be helpful for distributors of proprietary software. I'm not
100% opposed to people running proprietary binaries on GNU/Linux systems, but I don't think
it's a great idea for us in the free software community to be "giving away the store" to the
vendors of these programs. If they want to package binaries for a distro, they can build
packages appropriate to that distro.

Or, y'know, create static binaries, so as to avoid library dependency headaches.

Autopackage 1.0

Posted Apr 1, 2005 12:09 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

"This thing looks like it'd really only be helpful for distributors of
proprietary software."

And for me, and I'm the maintainer of a free software application.

Autopackage 1.0

Posted Apr 10, 2005 21:59 UTC (Sun) by FooBarWidget (guest, #10500) [Link]

So your "solution" is "grab the source & compile". Well autopackage is *not* designed for people like you. It's designed for people who don't want to compile things. You know, people like my parents, new Linux users, etc. In other words: people unlike you.

Apart from being one of the autopackage core developers, I'm also the maintainer of several open source projects. And telling everybody to compile the source code is not solution! You know, some people do care about having an easy way for users to install the software, even if the software is not in the distribution's repository. You say autopackage is only helpful to proprietary software, yet the only applications that use autopackage at the moment are 100% open source!

Autopackage 1.0

Posted Mar 31, 2005 10:22 UTC (Thu) by broonie (subscriber, #7078) [Link]

The package format used by autopackage apparently has some drawbacks.

Autopackage 1.0

Posted Apr 10, 2005 22:01 UTC (Sun) by FooBarWidget (guest, #10500) [Link]

Sigh, too bad joey's blog doesn't have a comment section. I keep posting this every single time. Read Mike's reply here.

Not the package type but the backend database that matters.

Posted Mar 31, 2005 11:01 UTC (Thu) by Wout (subscriber, #8750) [Link]

It seems to me that the problem with different package managers is not the package format (eg. rpm or deb) but the type of the backend database on the (client) system. If rpm, dpkg, ... all updated the same database when installing a package it would be possible to mix different packages on the same system.

If the maintainers of rpm, dpkg, ... would agree on a backend database format then we could all keep using our favourite type of package without having issues due to differing package types. Vendors of commercial software could then (in principle) pick one type of package and use that on any distribution.

Not the package type but the packages logical contents.

Posted Mar 31, 2005 12:55 UTC (Thu) by clugstj (subscriber, #4020) [Link]

No, the problem is that the distributions don't agree on what is in a certain package. If my package depends upon a certain library, which package is it in, and where is the library installed? The answer changes for SuSE, Fedora/RedHat, Debian, etc. The backend database is a technical issue, easily solved. The package name/contents issue is a social problem, not easily solved.

checkinstall ?

Posted Mar 31, 2005 16:25 UTC (Thu) by cdmiller (subscriber, #2813) [Link]

Why not just use checkinstall?

checkinstall ?

Posted Mar 31, 2005 17:19 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

Because it doesn't produce rpm's that work with many distributions? I've tried to make a krita
release using checkinstall, but failed horribly. The resulting rpm was just plain unusable, even on
my own system.

checkinstall ?

Posted Mar 31, 2005 23:25 UTC (Thu) by cdmiller (subscriber, #2813) [Link]

I have had no problems with checkinstall on debian, redhat, and mandrake, but recently the only thing I have packaged using it was an old asclock release. Use checkinstall if the unpackaged source is all that is available for the software you need until a package complete with dependency checking etc. for your distro appears.

Cacaphony of Packages

Posted Mar 31, 2005 18:33 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The problem here that autopackage is trying to solve (workaround, really) is the fact that still one cannot expect a binary built for one system to work seamlessly on another. Assuming the thing runs at all (LSB helps, but doesn't cover things like GNOME and KDE) the packaging is likely to be all b0rked, an RPM made for SuSE isn't going to install cleanly or correctly on RHEL or Mandrake and it'll be completely wrong on your Debian based system.

Currently the choices for a software creator are to:

A) Have their software picked up and distributed by a vendor
B) Spend a lot of time making packages and tracking dependancies for every platform you wish to support.
C) Bypass the package system entirely and make && make install
D) Loki Setup, Autopackage or InstallAnywhere

Right now this is a mess, but I don't see any solution in sight. The only way to fix this in a sane fashion is to have one packaging system, one filesystem layout and one dependancy tree (similar to how Debian and Debian-variants can easily work together). Basically RHEL, Fedora, SuSE, Mandrake/Connectiva, Debian, Gentoo will all have to go away and be replaced by a standard Linux. Since these people think

1) They have the "One True Way" so they're sticking to their OS
2) They need to differentiate in the marketplace (this is killer)

This will never happen. It isn't technically as bad as the old Unix Wars, everyone is dipping from the same source tree, they aren't fully forked from one another, but they have enough niggling differences to make them practically incompatable.

Anyway, a rambling $0.02

--Mark Tinberg

Autopackage 1.0

Posted Apr 1, 2005 4:15 UTC (Fri) by mcatkins (guest, #4270) [Link]

I'm surprised more people aren't worried by the fact that an autopackage
is an executable!!! What a wonderful vector for a virus!

We've almost convincing the windows people that running downloaded files
without looking at them very carefully is not too clever, and here someone
is suggesting the same for Linux!

What I'd like to see is:
1) a package format that is *not* executable
2) force the user to manually download, and install the autopackage
installer first. Better yet, why not put the autopackage installer into
the standard distributions, so after a while, everyone already has it?
3) Change the installation process of a package so that the first step
is to create a .deb/.rpm/etc suitable for the local system, from the
data in the autopackage, and then install that.
This way, autopackage files play well with whatever local
package management system is being used.

And doesn't alien already do most of the hard work? Or at least,
is a starting place.

1 is pretty-much non-negotiable, before I would use autopackage

Autopackage 1.0

Posted Apr 1, 2005 6:41 UTC (Fri) by khim (subscriber, #9252) [Link]

If you'll think about it it's minor nitpick. I mean: sure enough .rpm or .deb is not executable. Yet both have pre- and post- install scripts. Isn't it the same thing ?

As far as our packages can contain random code we can not be sure that "net-downloaded random package" will keep system unbroken. So neither rpm nor deb and of course not ebuild are suitable for such approach. Not really. Yet Autopackage makes problem worse, not better! This is my grief. This is not a packaging system - this is installer like InstallShit^H^H^H^HAnywhere plus packaging system (and later part is poorly made, BTW).

Autopackage 1.0

Posted Apr 1, 2005 7:10 UTC (Fri) by mcatkins (guest, #4270) [Link]

Thinking about it some more, you are probably right. I was thinking
that at least the package integrity, etc was checked before getting
to that point. But you're right - this doesn't really give you much.

I would maintain, however, that we shouldn't be encouraging people
to get into the habit of download+run (without putting on thinking hat).

Download+feed_to_some_program at least leaves open the possibility
that some checks occur, or could be added in the future, and thus is
a better habit to encourage - IMHO.

There is no replacement for "trusting" (to some extent) the source
of your packages!

My other comments still stand....

Autopackage 1.0

Posted Apr 1, 2005 10:37 UTC (Fri) by ballombe (subscriber, #9523) [Link]

> If you'll think about it it's minor nitpick. I mean: sure enough .rpm or .deb is not executable. Yet both have pre- and post- install scripts. Isn't it the same thing ?

No it is not. With .deb and .rpm, you can inspect the pre- and post- install scripts before deciding to install the package. You can also decide to extract the data without running the scripts.

You cannot do that in a documented way with the current autopackage format.

Autopackage 1.0

Posted Apr 2, 2005 20:11 UTC (Sat) by khim (subscriber, #9252) [Link]

And why the hell no ? It's just a script! Exactly like pre- or post- install scripts in .deb/.rpm! Sure if you'll find .rpm with pre- or post- install script 100Kb in size you'll probably skip this package (it's scary: what this #&*!^@&*#@ thing will do with my system?), but... difference is in quantity, not in size.

Basically: .rpm/.deb can be disastrous beasts, .package is always disastrous beast. First choice is better then second one, though not by very much.

Autopackage 1.0

Posted Apr 7, 2005 13:08 UTC (Thu) by mikehearn (guest, #29106) [Link]

Sure you can. The -d switch is documented and stable, it won't disappear anytime soon. It means running code, but it's all "in the clear" and you can read it first if you think it may be dangerous.

The -d switch puts the package into "debug" mode: it extracts the payload and the metadata into the temporary working directory, then dumps you into a shell so you can explore or edit the internals. At that point, all the scripts are available for your perusal.

Autopackage 1.0

Posted Dec 27, 2005 17:54 UTC (Tue) by dontunderstand (guest, #34777) [Link]

He Guys you really disappoint me... why not use the concept of softricity but now for Linux... That is the real sandbox idea, and easy to update, safe ... , using streaming