LWN.net Logo

Autopackage 1.0

Autopackage 1.0

Posted Mar 31, 2005 9:57 UTC (Thu) by khim (subscriber, #9252)
Parent article: Autopackage 1.0

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.


(Log in to post comments)

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!

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds