With Autopackage officially declared stable, there is now an easy way for developers to create up to date, easy installable packages. Expect an Autopackage article later this week at OSNews.
Autopackage 1.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
And now it’s up to the developers to package their software with through autopackage.
Eugenia, what about asking all developers on gnome-files to also use autopackage?
No, it is not on gnomefiles’ hands to make people create packages under any certain format. They are free to do it, and in fact some already do it. Gnomefiles.org has three download fields, the developers are free to fill them up with tarballs, debs, rpms, autopackages or whatever else they want. It’s up to them.
This is great to see.
Autopackage certainly fills a void for Linux, tools like apt-get, ports, and portage definitely have their place but the diversity and number of these ports systems is their downfall in some respects.
Before the flaming starts here, let me clarify some points:
1) Autopackage is not supposed to be a replacement for rpm/dep/apt/etc. It’s mainly for third party software – the distro will still provide system programs (including GNOME/KDE).
2) The Autopackage packages are supposed to be created by the same people who write the software and downloadable from the same place as the source tarballs.
3) Even though some think so, using autopackage to install stuff is not any less secure than installing a rpm/deb package. Just because the procedure of installing is the same as in “that other os” it doesn’t mean that it comes bundled with spyware and virus by default.
For more frequently asked questions, see http://www.autopackage.org/
From their FAQ:
Q. “If I install an autopackage, RPM won’t know about it!”
A. “As of 1.0, correct. For applications this isn’t a big deal. The biggest advantages of having RPM know about an application installed via autopackage are that you can query file ownership, and if you upgrade to a newer version in RPM form (for instance, your distribution installs it automatically), things will work cleanly. Neither of these are huge problems.”
I don’t understand this. I am 100% sure this can break DEB system badly, and can’t agree that this isn’t a “big deal”. I don’t know enough about RPM system though.
As far as I know, Autopackage installs to /usr by default (which is really bad enough — should use /usr/local, no?).
Now let’s assume that a user installed a software from Autopackage, and later, it’s packaged by distro. As files are already there in the same place, package managers will refuse to overwrite and baffle. (At least dpkg does this. It’s sane.)
How can this go with “Autopackage complements system package managers” mantra, I don’t know.
Nice.. I guess i can try it out on my LFS partition now. I tried checkinstall but it was too buggy, i wonder if this might be the answer.
It would be very nice if package managers could somehow be informed by autopackage that a new package has been installed.
This could be very easy to do, too. If autopackage would install a certain file to /var/autopackage/installed/, then all package managers could check to see if a piece of software is already installed. This would keep everybody happy.
Autopackage probably already installs such a file, right?
I see a great future in this. Hopefully, there will be some kind of notification feature for new software in autopackage.
I tried it. I downloaded one of their demopackages (Lincity) and tried to install it on Ubuntu (Warty). Well, autopackage installed a lot of files and proudly announced that it had added the program to the menu system..
Problem 1: The program wasn’t added to the menu system. At least not to the one used by my GNOME desktop.
Problem 2: When I tried to run the program all I got was a shared library loading error. Seems like dependency management is broken as well..
That looks more like a package bug than an autopackage bug. Try contacting the package author about this. Autopackage cannot fix mistakes that the packager makes.
If the package is buggy the autopackage guys shouldn’t put it on their “Try It!” page..
As I said: bad impression.
Absolutely noob friendly, I didn’t have the support framework installed and it nicely asked me if I wanted to install that. After confirming, it went off and fetched it for me, installed it and then proceeded with the actual package I selected for installation.
It also keeps user separation intact. While making software installation a breeze, it still holds all the advantages of deliberate software installation alive. Very good indeed.
It still has some problems with the new Gnome menu structure in 2.9 and it installs in /usr, while I personally would have prefered /opt, but overall very nice and user-friendly. When package-manager integration becomes available, there is abolutely no reason left not to package with this.
Removal of software was a walk in the park (despite me having to start autopackage-manager-gtk from the command-line). It certainly has the potential of drawing more people to Unix…
I guess that the age old “truth” about difficult software installation on FOSS platforms is finally dead.
Could somebody who is having problems with the menus in GNOME 2.10/Ubuntu Hoary please drop by on IRC or the mailing list so we can debug this?
Why do we use /usr?
We used to use /usr/local however there are too many distros that do not set up all the paths for this correctly, so various things broke badly.
Installing to /usr fixed all these issues and gives the user a much more reliable experience. If you dislike it however you can alter the default install prefix in the /etc/autopackage/config file.
> That looks more like a package bug than an autopackage bug.
> Try contacting the package author about this. Autopackage
> cannot fix mistakes that the packager makes.
This sounds like a problem that should be fixed ASAP. Packagers *will* make mistakes, and they should be prevented. Example: Prevent “missing dependencies” by not allowing a package to use anything that wasn’t declared as a dependency.
1) No, they should not list Lincity as an example package if its broken.
2) I have used both the Abiword and the gaim autopackage with no major issues on Hoary no less. Why not just use the deb version? Both of these packages update so frequently that the deb packagers cannot seem to keep up or reasonable should not need to.
Actually I was kind of impressed by the thing.
3) It does need some method to inform the system package method that the packages have been installed.
I look forward to the day that I can download a small distro like Ubuntu on one CD and get all of the other programs I want quickly by using autopackages.
The idea of just downloading a file and doubleclicking it to install is too ingrained in the psyche of most computer users to ignore despite the relative simplicity of say Synaptic tools.
Actually being somewhat of a Linux noob, I was looking forward to this. I tried to install Incscape just to test Autopackage but after installing the framework without any problems it said:
“Package ‘Standard C++ library’ was found but was of the wrong version and the correct version could not be located.”
Anyone ideas?
In any case, good luck to the developers, this really has great potential.
I downloaded 3 packages to try it out:
abiword, inkscape and supertux, and none of them worked!
Supertux installed but it wouldn’t run, the other two complained about wrong library versions.
I’m running Mandrake 10.0 by the way.
I have a question that I couldn’t find an answer to on the Autopackage website: when installing programs to “/usr”, does Autopackage install each program into its own directory, employing a link-farm to track headers, executables, etc.? If not, why not?
@tijs:
Try installing the compat-libstdc++ equivalent package for your distro. They should install it by default, but obviously don’t. There’s not much we can do about this except teach autopackage how to use apt-get and friends. This sort of thing is why we need a desktop Linux platform/base set.
@gambolputty:
If Supertux is crashing for you, this is most likely a bug in the SDL aRts driver. Run it like this:
SDL_AUDIO=alsa supertux
and it will work. At least it did for everybody else who had problems.
I’m afraid we can’t help you with library versions if you don’t tell us what happened. Right now the Gaim and AbiWord packages have excessive dependencies. The packagers know that and want to fix it but so far have not yet done so. We provide tools like relaytool to make this easy but they don’t currently use it. It’s up to the people writing the software to use reasonable dependencies – IOW don’t shoot the messenger.
If I understand this format correctly (I haven’t found any real definition of the format) it’s nearly imposible to completely extract all information of a package without executing all those scripts. I don’t like this.
Installing packages without proper dependency resolution and without package-manager integration just is a bad thing, as it breaks your Linux system. Keyword: “DLL hell”. So I consider people who have the feeling, that they need something broken like autopackage either should go back to Windows or they should switch to some sane distribution with up-to-date packages/easy package management system. Dislike the idea behind autopacking (“bring the installer mess you have on Windows to Linux”) that bad, that I wonder if some anti-autopackage clause in software licenses would make sense.
Andreas, you understand correctly. You can parse the comments at the top, they are stable (to a certain extent: each line itself is stable but they may change order). Information beyond that cannot be retrieved from the package, by design. These are not RPMs, so don’t expect them to work the same way.
Static analysis is not possible unless you want to manually read the shell scripts (which is entirely possible, run it with the -d switch). To extract the payload without running anything except the stub, which you can read with “less”, use the -x switch.
The biggest problem with huge platforms, like TeX, is that there are tons of soft above it.
Please, tell me, how should I install AuXTex+Emacs, all the biblio stuff etc. on e.g. Debian, when not using stock tetex, but LiveTeX or other automagically packaged flavour without a notice in deps database???
Every single TeX-related utility demands tetex installed, and it was huge pain for me to avoid all the deps: in fact I spent 50MB+ diskspace for Debian tetex just to get rid of the deps (It was much quicker for me than reading tons of docs to find how build dummy deb every time tetex gets upgraded).
As long as autopackage is not using package database, it is just a toy for not so complicated programs, I think. I do hope it will change, for we all need a good universal way to propagate linux progs!!
First off, I think autopackage is a great idea and really needed. So I’m really quite excited about the first release of autopackage.
However, I just found this critizicm (the same issue Andreas already pointed out) and am wondering why the devs chose the implementation they chose and how they respond to this.
http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys…
Autopackage cannot be supported by Alien anyway. The design is fundamentally different from RPMs/DEBs. While RPMs and DEBs are archives with metadata and a bunch of files that are installed to static locations, autopackages are scripts. As Mike mentioned, static analysis is not really possible. This is by design: packages must be flexible enough in order to deal with all the differences between distributions, which is why they’re scripts.
Yes, the supertux autopackage doesn’t add shortcuts to gnome (2.8.3) menu either. That’s not a problem with autopackage, but with the package itself. To everyone complaining about broken packages being on their “try it” page, it’s not. It’s on a 3rd-party package page, which isn’t even hosted on autopackage.org.
Yeah, Joeys post is mostly hot air and rhetoric. These things aren’t packages like RPMs/DEBs are, and that’s by design. That doesn’t make them bad, it makes them different.
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. We have enough problems supporting all the random broken stuff out there (in which Debian is most certainly included) even when we can run arbitrary shell scripts and use any C programs we like. Trying to give the user a robust experience when having to work from within the confines of a different package format would be insane.
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.
What can I say, the rest of Joeys post is just insulting and meaningless. Designed by monkeys indeed. But what do you expect? He’s a Debian developer, and I’ve yet to meet a Debian developer who does not believe the solution to every problem is “use Debian”. At some point he’ll realise that if Debian and apt-get were so hot, there would be no such thing as Ubuntu “main”, but I’m not holding my breath waiting for them to realise this. They’re apparently more concerned about debating whether the nv driver is free or not.
Ok, thanks for clearing that up.
Keep up the great work!
I think that Mike Hearn and his fellow autopackage developers deserve more credit than they do now. To me it looks like they have at least tried to create a solution for one of the most difficult problems on linux: software installation / maintaining.
@ Eugenia (2nd post):
I’ve never stated that developers on gnome-files MUST use autopackages. Of course they are free to choose whatever they want, but: the succes of Autopackage depends on the amount of developers which are going to use it. Now, I think it has potential and I thought that you did too. Unfortunately I don’t have a database with many (gtk)developers, but you do… So I think it’s at least easier for you to globally contact those developers and point them to autopackage than it’s for me…
I’m not trolling here but it seems to be that the best option still for installing software on a Unix system is OSX DMG based installations. You drag an Icon into the Applications folder and your done.
http://www.Coolcrap.org – Tech Gadgets and Gizmos
This is really good. Now I guess it is up to PR/marketing/whatever-we-want-to-call-it 🙂 It would be really good if autopackage is used as a primary way of distributing software, a bit similar to current tgz at al – this means that .a would be mandatory and rpm’s, deb’s etc. optional.
I guess that also a real uniform Linux platform is required in order to achieve Windows like installation ease? (like – double click and forget :-). Is it true that LSB is just not enough?
I have so far tried both gaim, gimp and lincity and all of them installed without a single hitch. I have yet to try it out on my debian box though..
I certainly look forward to what this might bring in the future.
Ok, if autopackage is so great then you obviously can explain how to solve real-world problem: installation of programs in shared environment.
Here we have more then 1000 users on one system – from different departments and so on. So quite often we are forced to install strange stuff for this or that laboratory. In a lot of cases we can not be sure there are no troyans or anything in what we are installing. So we demand from requestors clear installation instructions – to be run under root. If intruction includes anything we can not trust started from root – tool is not installed.
With sane package formats (like .rpm) you can just scan few pre- and post- install scripts (usually one-two liners) and you are all set. With ^%#!@&@!^%# InstallAnywhere or similar abominations the only way to do it is to install it on sacrificial system and then check changes. What’s situation with AutoPackage ?
If the only way to install something is to run random code with root permissions then I’m forced to say “thnx, but no thnx”. And I’m not even Debian developer… yet I try to avoid random installers with root permissions – unless I’m really forced to use them: it’s easy to create sacrificial account to try program but sacrificial system is not worth the effort in 90% cases.