Autopackage 0.4, codenamed “Better late than never ;)” is now available. Version 0.4 has most of the local architecture in place, with a terminal front end and a working GTK2 based GUI frontend. It can build, install, verify and uninstall packages of medium complexity (mplayer, gaim etc).
Autopackage 0.4 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
Looks nice, but, how can the installer be affected by the distro its installed on?, not every distro uses the same kind of packages.
So what happens if GTK2 is not on the system? Can this thing resolve its own dependencies ?
thats the purpose of the project, installing packages on any distro.
Maybe that’ll be a v2.0 feature 🙂
Or maybe they can just statically link every single lib that leads up to GTK2!
Autopackage might just turn out to be vital to the success of desktop Linux.
Wasn’t me who posted this! I guess Eugenia is on the announcements list or something.
If you don’t have GTK2 you just get the text mode installer. Nobody has packaged GTK2 using autopackage and probably nobody should – it’s a core system library and should be provided (and updated) by your distribution, not gtk.org
Eventually (0.7/0.8 timeframe) we want to be able to use apt/urpmi/emerge/yum/whatever to resolve dependencies like GTK, but for now that code remains unwritten.
Hi Mike
Is there any time frame within which this project is going to having some real implementations. like stuff which i can actually use. It would be nice to know that. a lot of people are mentioning this packaging system as a vendor neutral standard which can help software be packaged in a more universal way.
regards
Rahul
Well it’s usable now. Go try the example packages and see!
The main problem is that if you build a package with it today, you won’t be able to do upgrades very easily. Every time we release a new version of autopackage you’d have to at least rebuild the package, maybe update your specfiles. We also don’t support package upgrades which is the last major must-have feature for people to really use this.
What version 1 means is that we won’t break your packages when we release new versions of autopackage, and the design and API are solid so you won’t have to keep updating your specs.
If you want to start using autopackage now, please get in touch with us on the mailing list or via IRC, and as long as you promise to help us fix things when things break we can help you make beta packages to put on your website.
The other problem is that we haven’t fully documented all the changes people may need to make to their software to make them binary portable. We’re going to work on improving the documentation again for 0.5
Finally we want version 1.0 to make a big splash and not have any serious weak points that people can criticize it for, as I think we’ll be judged by the 1.0 release. This might be a mistake on my part, I’m not sure how many people feel it’s usable already. So, I want 1.0 to have features like native package manager integration.
All things considered we’re hoping to have 1.0 done by the end of this year, but that might be a bit optimistic. It’ll be faster if you help!
will it be able to do unattended installs so for example sysadmins can use it to remotely install/upgrade packages on a large number of computers?
Yes, it already can (seeing as we dropped user interaction as a prerequisite for 1.0)
Hi
The guys doing rpm development had specifically depreciated interactive installation in favor of the ability to do unattended installation at all times.
they claim that a wrapper or doing it after the installation should cover that problem. i believe that they are right because eula’s conflict with unattended installation requirements. how do you plan to solve that?
regards
Rahul
Support for proprietary software is secondary to open source software for us, however we will support EULAs in future – in fact there is already some code in there for it, it’s just not activated yet.
User interaction will be reconciled with unattended installs by writing a frontend that automatically accepts the defaults. Therefore as long as you accept the EULA at some point there is no technical difficulty with having it done automatically.
“The guys doing rpm development had specifically depreciated interactive installation in favor of the ability to do unattended installation at all times.”
That’s something we’ve thought about since the beginning.
Every user interaction command MUST provide a sane default. If the user turned on “silent install” (no questions asked), then those default values will be used.
In the documentation, we warn packagers to use as little user interaction commands as possible. And then they use them, they must provide a sane default value, because the user may not see any interactions at all.
Autopackage might just turn out to be vital to the success of desktop Linux.
Right, I hope it works out for them.
Thanks to Mike Hearn & co. for a great project!
Wow, really looking forward to the integration of the planned features!
I love this… i tryed one of the packages (gaim) it VERY quickly installed into /home/$HOME/.local & at first i didn’t understand it, cause i saw no download for the base pkgman so i just saved gaim.package to my desktop made it Executable & ran within a few seconds i was running gaim 0.76cvs…. this is awesome (thought i plan to go back to .75 cause cvs scares me sometimes….)
all in all I give it two thumbs up & thank you for what you are doing….
I think that there should be a distribution policy metadata document, perhaps with some sort of embedded scripting language in CDATA sections, which a universal package manager could honor. Any distribution which wanted to participate could include this standardized document, which would include such information as standard paths, distro-specific ways to query for certain types of relevant settings, etc. Hopefully this document wouldn’t get too complicated.
This could be to installers what autoconf is to package building.
This is exactly what im working on in my free time[ not much of it currently tho]
im trying to make a simple installer for Vectorlinux[ it is slack based ] But the focus is on giving options like
do you want an icon on the desktop,
do you want a menu entry?
information can be provided in a standard format
ie path to icon files and other stuff not included in the install script.
however, where the menu entries are to be written change with each WM. So if all WMs implement a common API,
like CreateMenuItem(const MENU& ) etc.. where MENU objects could be constructed from the info provided with the package.
then along with the install script which currently just moves all files to the appropriate directories, some code to create interface elements can also be included;
Also uninstallation information should include the interface components too!!
i wont be working on this for the next month or so; so if any one is interested please write to me at
cintyram yahoo com
@ .
i will be glad to discuss.. also i hang out in the irc://irc.freenode.net/#vectorlinux room in the afternoon EST on wednesdays. will be more than glad to help any one;
cheers
ram
http://www.lingows.com
info lingows com
@ .