I wrote an article a while ago on Linux packaging and Autopackage. There seemed to be quite a lot of interest in it so we got version 0.3 released today.It’s so easy to test – just download the package you want to try and run it, it’ll download and install the support code automatically.
We have a GTK+ 2.x GUI now, you can see it here.
We have a Gaim 0.67 package which is pretty well tested, and a few others (not quite so well tested), but they should be enough to give you the idea of where we’re going and to test this new release of autopackage.
3 hurrays for Mike & Co!
Autopackage impressed me from day 1 and it still does so.
/me puts up 3 thumbs
I just tried it out, with Visual LDD, and it worked like a charm! 2 mouseclicks and entering the root password once (which was due to the first-time use). That makes it easier to use than RPM, which is the ‘native’ packaging format on RedHat.
I’m impressed, to say the least. — Keep going!
Autopackage looks really great, and I’m very impressed with it, but it’s gonna be a challenge to get people to use and accept it.
Perhaps you should write integration parts with popular package management systems…
/me likes the thought of having such a GUI for portage.
This really does seem to be the future of packagemanagement software on any platform. I think Mike and tthe rst of the people contributing to the project are doing a great job!
Hopefully it will be embraced by KDE in v4!
http://www.kdedevelopers.org/node/view/172
autopackage.org will msot likely have little trouble in being adopted if it keeps with its goals fo being easy for both developers and users!
This is one of the most crucial projects for Linux, more important even that Ximain Evolution for example! I would gladly trade it for a fully working autopackage with all the 1.0 features and few bugs.
BTW: That’s saying a lot, Evolution is my current Linux PIM suite, though Aethera looks interesting too as does Kontact.
In my test, I am not connected to the Internet. Is there a way to install without the need to grab file(s) from Internet? Just like RPM or DEB. I ask this because in my working environment, connection to Internet is purely HTTP. I hope to download whole package via HTTP and install it
for an Add/Remove programs frontend too, or is it only for installing packages.
something like this:
http://www.popularshareware.com/Add-Remove-Plus!-2003-screenshot-24…
Is there a remove gui?
something like this:
http://www.sharewaresoft.com/Add-Remove-Plus-2003-screenshot-3141.h…
or hopefully a lot better with apckages categorized, easily sortable by date, size, most used, etc.
>> Autopackage looks really great, and I’m very impressed with it, but it’s gonna be a challenge to get people to use and accept it.
No no no, it’s going to be a ‘challenge’ to get _developers_ to use and accept it, not users.. (remember, autopackage downloads/installs itself when not installed on the system)
Why should they (the users) not choose to d/l an autopackage instead of RPM/tarball/whatever if the former is much easier to use and does much more work related to system integration of the packaged program?.
There’s almost no cons with this system so I really don’t see any challenge..
/me, being a developer for an unreleased OSS project, is definitely going to use it, so that’s 1 developer less to be convinced
I’ll promise to convince lots of other devs as well
The download occurs when the support code is found to not exist. Currently, is does not search in the launch directory for the support code before it goes out to the internet.
To manually install support code:
download http://autopackge.org/downloads/autopackage-0.3.tar.bz2
expand archive and execute autopackage/INSTALL file.
Then if you execute any of the packages, the support code is found and it continues to finish the installation. If you want the GTK front end, it would be just like any other package installation – download and execute.
To remove packages and autopackage itself (user or root installs):
package remove gaim visual-ldd autopackage-gtkfe autopackage
Enjoy.
Looks simply amazing. I would love to see a common packaging format, compatible between all distributions. If you could convince most developers to use this packaging format, I would definitely consider giving Linux another try.
This is x86 only right?
Or can it do others, or even multiple architectures, in one .package?
Are there plans to port this to other ( non linux ) platforms, *BSD, UNIX, BeOS, MS Windows, QNX, Mac, etc… Just for fun I’ve tried compiling under FreeBSD 5.1 but I got an error having to do with getopt being too old. Autopackage brings back memories of the Loki installer, sure hope it will be ported to other platforms in the future.
Excellent, excellent, so far so good! Keep it up, guys!
LOL, that would be a disaster using cygwin for that, there really is no point either, we should keep our advantages not give them to all the other platforms!
Besides, Windows’s isntaller is alright, sure it sucks for the system but for the suer it’s pretty good. There is a lot of work to be done on the current autopackage, I don’t think there will ever be a time in which the developers will think “Oh, well we added every feature and fixed every bug, let’s port it to Windows!”
We shoudl just improve our *nix version instead of wasting resources porting IMO.
I also think it would be an incredible amount of overhead porting it to non *nix platforms.
I sure hope it won’t be ported to to oher non *nix platforms in the future.
Nice work. BTW, the word is spelled “dependency.” I don’t get why so many open source projects make the same spelling error.
<gush>I think this is THE most important piece of software for Linux right now. Installing software is such a hassle for mere mortals to do on Linux right now and finding recent packages for most distros is difficult. I don’t think you will have any trouble getting developers to package their software with this. Note that they are not trying to replace RPM or DEB. Those will be useful for distros but for the end user trying to install a package that was not included in your distro this will be a godsend</gush>
I just started learning linux last week. I picked a fancy book with came with red hat 9. we’ll basically i love it! there are a few things that bug me that in my opinion will prevent linux from taking over the desktop. the number one thing is packaging. i tried to install 5 or 6 different programs this week each one had a different way to install, some used the sh command some used ./blah some had a script to run. and neither piece of software left an icon to run nor did they tell you where to find it after it was installed. dont’ even get me started on the missing library issues and dependencies, some had the gaul to make me compile it myself! Linux won’t do as well with the newbies this is resolved after that then watch out… perhaps i should run gentoo or freebsd i here very good things about the ports system…
This is great. Please keep working on this. I can see this being a very important piece of software.
Ok really wishful thinking but will there be some sort of mass convertor from another package formatter to this?
Its probably unneccessary, but what i mean is there are so many repositories out there for deb/rpm etc. If autopackager could say download these and install them too good, i can just imagine me using Mandrake and yet taking full advantage of debian’s repositories.
On the other hand that probably may be difficult. But if there was a tool that could convert debs to package, then all the repository admins could just convert their repositories into the requisite format rather rebuilding packages by hand (ya i know u could script the whole damn thing, but wouldn’ convert2package *.deb/rpm be simpler?). It wold save time and probably would make ppl more eagerfor this format.
Especially since (correct me if i am wrong), basically rpms debs are a compressed set of files with some additional information right? So such a conversion tool wouldn’t have to do that much work would it?
Also when his thing is ready is there any way to get this pushed as a standard packager like in LSB compliance? But i guess if its good enough it will become popular and that way it would become a standard.
Plus i think the biggest advantage of autopackager would be that every distro needn’t maintain its own personal set of packages for every application. Will probably remove a lot of redundancy.
Also when someone is creating a new distro, he needn’t create it based on a distro chiefly due to the available packages for that distro. He can focus on other things.
I know all this is kind opf vague, but i am getting the idea across right?
>> Plus i think the biggest advantage of autopackager would be that every distro needn’t maintain its own personal set of packages for every application. Will probably remove a lot of redundancy.
Windows: uses CAB for OS components, InstallShield (or any other installer system) for 3rd party applications.
Red Hat Linux (example): uses RPM for OS components, Autopackage for 3rd party applications.
Seeing the point already? GNU/Linux is becoming more like Windows, yay!
(but this time, it’s a good thing)
I just stumbled onto EPM yesterday, which seems like having something in common.
It doesn’n resolve dependencies, but it also supports other Unices.
http://www.easysw.com/epm/
You guys might want to check it out and see if you can use some of their code and support more platforms…
The problem with linux…..
The problem with you is that you don’t use the right tool to install software. Installing software only with rpm, is just like compiling a software only with gcc.
For the second one, it’s quite easier to do : $ make
For the first one, you must install and use yum
http://www.linux.duke.edu/projects/yum/
That doesn’t mean that gcc is a bad compiler or rpm a bad software installer. They are some good critics against rpm
in the article of the author (espacillay rpms between various distros), but this one is a troll.
I agree it should be by default in the distro. It is in Mandrake (urpmi), and it will be in the next Redhat.
I am using redcarpet to install *.rpm files and it works fine for me – what is the difference between autopackage and sth. like redcarpet, it seems to me that both do the same job, i.e install software and resolve dependencies with the difference that all the packages would have to be repackaged if you want to use autopackage – redcarpet can use .rpm and .deb … unless autopackage can upgrade your distro like ‘apt-get upgrade’ and that distribution independent – that would be awsome.
I wrote They are some good critics against rpm
in the article of the author (espacillay rpms between various distros), but this one is a troll.
The troll was in the article written in 2002, but doesn’t appears anywere on their site now . A good troll is a dead troll, so all is fine.
their FAQ is very informative, their website is nice, and autopackage seems very interesting.
Hi,
It’s good to read about peoples successes with the software. Here are some answers to your questions:
* Perhaps you should write integration parts with popular package management systems…
We intend to have integration with at least RPM and maybe DPKG and portage in the future. Integration in this context means:
* We will register software installed via autopackage with the system database using either the generic short name of the package, or if specified a name specific to a distro (so if a popular repository chooses a certain name for a program you can still interop to some extent). That means you can use RPMs query file, list files, and remove functionality, and other RPMs that depend on that package should (cross fingers) still work.
* We will attempt to locate distro specific packages off the net to install dependencies where possible, rather than other autopackages. On systems like Debian and Gentoo, that means integration with apt/emerge and so on. On systems like Red Hat, it’ll probably mean bypassing yum/apt and going direct to a repository and downloading the files ourselves.
This code hasn’t been written yet though. Volunteers needed.
* In my test, I am not connected to the Internet. Is there a way to install without the need to grab file(s) from Internet?
At the moment you have to “hack” around it. There are lots of little things like this we need to polish, which is why it’s a 0.3 release, not a 1.0 release
Curtis told you how to do it for now though.
You can also download the autopackage core code then use the setup script in there.
* Is there a GUI … for an Add/Remove programs frontend too, or is it only for installing packages.
There currently is no such GUI. In a future release we will make uninstall and verify output via the frontend protocol, which will mean that once both KDE and GNOME support the actions part of the .desktop spec, you will be able to right click the menu entry/launcher and choose “uninstall” or “verify” and in future “update” too. We may provide an explicit UI for this too, but there are currently higher priorities. Typically we’re aiming for tight desktop integration – if you aren’t running KDE or GNOME, that means you may still have to use the command line sometime (but you probably don’t mind that).
* This is x86 only right? Or can it do others, or even multiple architectures, in one .package?
At the moment we do not have any mechanism for dealing with multiple architectures. The plan is to support “mixins”, which are super light weight packages (basically just tarballs in fact) that are downloaded or selected by the Prep scripts and overlayed onto the package payload. That’s one way to support multiple architectures (and for instance multiple C++ ABIs) without bloating the main package too much, but requires careful thought.
The other problem is that most people use x86 – at some point I want to research cross compilers and figure out how easy we can make the process, so the same build process can spit out PPC binaries as well. We’d probably draw the line at PPC, I don’t know of any other architectures other than x86 and PPC which are popular on the desktop.
We will get to this feature eventually, but volunteers are needed as it’s not a high priority right now.
* Are there plans to port this to other ( non linux ) platforms
No, there are no such plans. I don’t intend on this being portable outside of Linux, it’s hard enough just supporting different Linux distros, other platforms entirely would be insane.
Remember this system is practical because Linux distros are basically binary compatible. Other systems are most certainly not bincompat with Linux (at least not without emulation). Being mostly based on shell scripts, we take advantage of every feature available in the GNU utility set, variations between different versions of the toolset are enough to break us, supporting a different set entirely is out of the question.
* Nice work. BTW, the word is spelled “dependency.” I don’t get why so many open source projects make the same spelling error.
Where is it spelt incorrectly? I thought I had got rid of all the incorrect variations of this word, but I guess I still use the wrong form by mistake sometimes.
* Ok really wishful thinking but will there be some sort of mass convertor from another package formatter to this?
It’s wishful thinking. autopackages are structured very differently to RPMs or DEBs. They must be written from scratch.
The intention is that we’ll be able to download and install packages built for your specific distro, so for instance on Debian we would use DEBs to resolve dependencies where possible, but it’s not a good idea to try and use DEBs on Mandrake, or vice-versa.
Especially since (correct me if i am wrong), basically rpms debs are a compressed set of files with some additional information right? So such a conversion tool wouldn’t have to do that much work would it?
That’s what all packages are, basically
The key is in the contents and structure of the additional information.
Also when his thing is ready is there any way to get this pushed as a standard packager like in LSB compliance?
autopackage is not suitable for standardisation, it’s very complex and I can’t imagine anybody wanting to implement their own version of this. If we do our job well, popularity will take care of standardisation.
* Looked at EPM?
Yes, we’re aware of that project, our goals are somewhat different. EPM generates packages specific to each form of UNIX they target, as well as simplistic self extracting packages. We are focussed purely on Linux, and making the packages integrate well with that platform, rather than portability.
* What is the difference between autopackage and something like redcarpet?
Red Carpet works by having Ximian choose software, then building packages for each distro they support separately. They do not support Mandrake for instance, nor Debian. We try and support almost every distro (or to be more accurate, we adapt to distro oddities as we find them, as most distros are largely compatible). Under the hood, they work very differently – for starters anybody can make an autopackage, whereas to get on Red Carpet you must talk to Ximian.
I hope that helps
thanks -mike
Can be spelled both ways. Check before posting.
de·pen·den·cy also de·pen·dan·cy
n. pl. de·pen·den·cies
1. Dependence.
2. Something dependent or subordinate.
3. A territory under the jurisdiction of a state of which it does not form an integral part.
Source: The American Heritage® Dictionary of the English Language, Fourth Edition
Copyright © 2000 by Houghton Mifflin Company.
Published by Houghton Mifflin Company. All rights reserved.
… being developed on Slackware Linux? I’m just crious:) I would like to know if you people still people still use Slackware.
No, me and Hongli use Red Hat, Curtis uses Debian (I think). Not sure why you think Slackware is involved…
Finally!!!
I wish you good luck. (I hope Red Hat, Suse, Mandrake, Lycoris, Etc, adopt it).
“I wish you good luck. (I hope Red Hat, Suse, Mandrake, Lycoris, Etc, adopt it).”
(not just) imo this is one of the most important projects to make linux ready for everone’s desktop, and it really doesn’t get the attention from the big distros it deserves(or, to be more precisely, none so far), likely because they haven’t understood its tremendous advantages/implications.
i just wish there would be more developers in the linuxworld with mike’s focus on usability and integration, and less geeks, because there are still enough big constructionsites needing attention.
keep on the good work.
This all looks very good. I hope it will gather acceptance someday soon (since this project will be worthless unless people actually make packages for it). I am convinced that this is one thing that Linux REALLY needs to succeed on the desktop. I also just wanted to acknowledge that this is HARD stuff. I think a lot of people don’t realize how fragmented the current situation is.
Systems that rely on repositories (RedCarpet, apt) work great for free stuff (as long as the repositories are well maintained). However, for non-free software, these systems are worthless. Linux NEEDS a system where the software developer/company can distribute applications generically rather than per distro. Otherwise, getting commercial application support is going to be very difficult (and will likely be limited to the major distros only).
This one looks promising. Should finally solve the installation nightmares on linux.
hi
Dictionary.com says it’s a variation, but Merriam-Webster has no dictionary entry for “dependancy.” I suspect it’s also not in any printed dictionaries.
http://www.m-w.com/home.htm