Autopackage, the distro neutral packaging framework for Linux systems, got the release of 0.5 with major improvements in nearly every area have been made, including:
– Improved documentation on binary portability
– Big improvements to the apbuild binary portability tool.It can now automatically remove unnecessary link options as a program is compiled.
– A new program to make soft linking easy has been added (relaytool).
– Package release numbers have been implemented
– Packages can now upgrade themselves in a simplistic style (by automatically removing the old version)
– Native RPMs for the support code, for those who don’t want autopackage to install it automatically. These should work on pretty much any RPM based distribution.
– You can list the files of an installed package now
– You can once again run a .package direct from a graphical file manager, and it will all just work.
– A new graphical root password prompting program, autosu, is used to ask the user if they have the root password while still offering them the ability to install as non-root if they don’t have it.
– New APIs for installing KDE mime files
– Lots of bugfixes!
Autopackage 0.5, “Deja vu” 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
are OSS projects and distros going to support this when it gets stable or is this just going to be another “oh look at that, how interesting” type project?
The great thing about autopackage is, that it doesn’t matter. You can simply package your application with autopackage and everyone will be able to install it easily (the installer will install itself if it isn’t already).
There are already some projects which are interested in this and at the very least I’m hoping that it will sooner or later replace use of the outdated Loki installer. But I’m sure that “regular” developers will also soon want to enjoy the benefits of providing easy to use binary packages to their users without relying on distribution support or manually packaging the application for countless distributions (which requires to have them installed in the first place…).
As I recently installed a clean Fedora Core 1, I just used the Gimp2 test package. I downloaded the .package file, made it executable, ran it. It asked me to install the installer, I said yes, it wanted my root password (I could say no password for user installation), then the graphical installer started and asked for my password again (and again it was optional), then the installation started with lots of progress and I had to click one more time on “Ok”, now Gimp2 is working fine on my system (it failed to set up application menu entries though).
The next autopackage I’ll use will obviously not require the installer installation anymore. That’s just how easy it is.
well, that is my point. for it to work, developers need to package their software for it, and they must have the server software running for the dependency resolution service to work.
but what is the installer like? is it sort of like the Mozilla net installer where it downloads the dependancies from the web and all the user sees is a progress bar on the installation? that would be a huge leap in insatiability of software suites.
”
but what is the installer like? is it sort of like the Mozilla net installer where it downloads the dependancies from the web and all the user sees is a progress bar on the installation? that would be a huge leap in insatiability of software suites”
just try it out
This is great. I wish all luck to the autopackage guys. Now lets just hope that autopackage receives acceptance in the Linux world.
This project is so very promising. Let’s hope this can be made painless on linux and get some good widespread adoption, awsome stuff!
having just read Spark comment I thought I would give it a shot. I ran gime2x.package, it downloaded autopackage, autpackage installed gimp2.
The introduction to autopackage was posted here some time ago.
http://osnews.com/story.php?news_id=2307
wow
sounds great! keep up the good work developers!
because of it being distro-independant, i think autopackage could remove a major roadblock for commercial 3rd-party software vendors to offer their stuff on linux without having to worry about deps and/or having to package for a bunch of distros – means to avoid unnecessary overhead.
autopackage yet doesn’t get the attention it deserves, but it would very nice if some company or distro would step forward to support it.
it is also imo an important project to make the linux desktop more userfriendly and therefore help its adoption.
if in the future a distromaker can create a interface for his distro so that when you try to install a .package it will allso check if your distro allready have some of the dependecys of that package and request the distro to install them rather then getting it of the net. most likely we are talking about some kind of interface hooks in the distros package manager software (like say apt-get, rpmdrake and so on) that can be more or less distro neutral with the right way of requesting packagename and version…
lot better than RPM but i’ll still continue using my dpkg to install packages, there’s nothing easier! (and it works)
-> though still a good project
Autopackage already checks for required dependencies but instead of relying on the package database it looks directly at the file system.
Integration into RPM, Apt, Portage etc is a planned post 1.0 feature and it does’nt have to involve the distromakers. This will use the already installed package system to install the required dependencies and possibly to add the installed software to the package database.
Great to see such progress. I’ve been following autopackage for some time now and I’m glad to see it doesn’t seem to be slowing down at all – keep up the good work!
I certainly hope that some developers start packaging their software this way – it could really mean a turningpoint for Linux.
Propably even for those projects where you only get the MacOS X and Windows binaries but no Linux binaries at all or the typical “provided by a 3rd party – not garantueed to work” packages, that for some reason is available in all flavours but *just* your distro’s missing…
Maybe… just maybe this might make an end to the “Hey you’re using Linux – compile it yourself” attitude… though I can understand this in the current situation where its just not possible to make a universally usable package for every distro.
although apt-get and urpmi have served me well in the past, autopackage is much needed, especially for all the smaller projects that don’t necessarily attract packagers attention and where the maintainer would like to concentrate on something else that producing and maintaining a flurry of various packages.
Excellent stuff really.
I’ve tried it when it was in 0.3 or so release and it was already showing lots of promise. I really hope it’ll be ready for the next release of my game
As spark said, I believe it will be really great for games(like mine
, because games are IMO an utterly non distro dependant thing(or should be at least).
well my point is that if the needed libs that the package checks for are allready available on the distro’s disks but isnt currently installed for some reason then why should the package download the libs of the net rather then poke the distros installer into action and have it get and install the stuff requested…
That’s the plan. No ETA for that, except “some time after 1.0”. Basically when somebody writes the code to do it ….
nice, that will make it interesting but it still will force the software to talk to some sort of system like apt or urpmi unless the installer have a comprehensive database of every lib package shipped with every distro it supports…
We’re intending to bridge to apt/yum/urpmi and so on. It’s mostly a matter of code and getting the right metadata into ths skeletons. The latter will probably come before the former.
you first have to create a generic system before you pass the values to a more spesific system for the diffrent software used. i just wonder what will happen if say you have both apt and yum present on a system (like som fedora installs have) as then there can become a bit confuseing as to what software to talk to. but i guess stuff like this will be sorted out in due time.
i realy do like the idea of the user only install to. it makes stuff interesting on a multiuser system where the kids may want a lot of games but dad dont want to have the system flodded by them and can then set a max size on the kids install area;)
and hell, if a corp just wants to release a standalone software package they can then do like opera do and staticly link. the binarys and install files will become a bit bigger but the corp get a lot less problems to work with:)
looking forward to 1.0 and a hopeful adoption by mainstream software houses…
i wodner if in the future konqueror and nautilus (among others) will know what a package is and maybe remove the need for marking them as +X. i fear that is the one step that will put joe user off most of the time…