Autopackage, a Linux distribution neutral binary packaging framework has released a new version. New features include:
First API stable release, Self contained Installers, Multi architecture support, Better documentation, Support for internationalisation, Support for Gconf schemas, A brand new graphical management software for easy uninstallation of autopackaged apps. A 1.0 release is expected by Feb 2005.
If there is one thing I really miss from Windows, it is easy software installation and apt-get doesn’t cut it. (no license, no install options, not distributed etc.)
will redhat/novell/suse/mandrake/{other 300 names} make auotpackage their default installer tool ?
will it be universally accepted ?
There are better, faster alternatives for that, such as RPM and DEB.
They don’t have to. RPM/DPKG intergration is planned for post 1.0
As far as i can think, the existing packaging in linux is much better then the windows-type installation. Ofcource, their needs to be more development but the concept will prove to be more suited to the future computing with internet becoming more and more integrated with the desktop.
Why would i want to go look for a software’s website and installer when the existing package management allows me to search the ever increasing repositries from a program interface. And the system-wide upgrade, can windows-type installers do that…?
You have got a point if you want to centralize the installation of software. But no one is used to that when the apps are produced and distributed by people that you haven’t ever heard about. All the control of the current installation procedures on Linux is not what people expect most of the time.
I want to try out Autopackage and see if it’s enough to get independent from the system-dependent installers.
Mike H wrote about this…
<QUOTE>
Making desktop Linux software installation easy
28th September 2004
Isn’t it easy already? No … technologies like apt have serious
drawbacks we should recognise:
* Centralisation introduces lag between upstream releases and actually
being able to install them, sometimes measured in months or years
* Packaging as separate from development tends to introduce obscure
bugs caused by packagers not always fully understanding what it is
they’re packaging. It makes no more sense than UI design or artwork
being done by the distribution
* Distro developers end up duplicating effort on a massive scale. 20
distros == the same software packaged 20 times == 20x the chance a
user will receive a buggy package. Broken packages are not rare:
see Wine, which has a huge number of incorrect packages in
circulation, Mono which suffers from undesired distro packaging, etc.
* apt et al require extremely well controlled repos, otherwise they
can get confused and ask users to provide solutions manually : this
requires an understanding of the technology we can’t expect users
to have.
* Very hard to avoid the “shopping mall” type user interface, at
which point choice becomes unmanagably large: see Synaptic for a
pathological example of this. Better UIs are possible but
you’re covering up a programmatic model which doesn’t match the
user model esp for migrants.
* Pushes the “appliance” line of thinking, where a distro is not a
platform on which third parties can build with a strong commitment
to stability but merely an appliance: a collection of bits that
happen to work together but may change in any way tomorrow: you can
use what’s on the CDs but extend or modify it and you void the
warranty. Appliance distros have their place: live demo CDs, router
distros, maybe even server distros, but not desktops. To compete
with Windows for mindshare and acceptance we must be a platform.
Apt does have its place: useful for servers, core OS packages…
</QUOTE>
“Why would i want to go look for a software’s website and installer when the existing package management allows me to search the ever increasing repositries from a program interface.”
We’ve heard of the “apt-get install foo is easier” argument from many people. Yes, it’s a valid argument. However:
– This is assuming the user knows the name of the software. The apt-get interface is good for experienced users, but not for new users.
– Having a repository for each distribution wastes manpower. We don’t have unlimited manpower.
You should read the website and the FAQ. We’ve already answered this kind of questions many times.
And we have some plans to implement a repository-like interface ala apt-get/yum, but it will be post-1.0.
I’d note that there’s nothing inherant in decentralised packaging that means you can’t do an apt-get style interface for it. You could easily have one in fact, but it’d be based on a DNS style resolver heirachy.
The fact that you can grab it direct from the website is a bonus, but it doesn’t have to be that way. By changing the fundamental way we package software, we can support apt-get style user interfaces, MacOS X drag/drop style user interfaces, and Windows setup.exe style too.
Ah, Autopackage.. one of the many projects I’m really looking forward to.
That uninstallation app looks very nice, btw.
I just hope it won’t suffer from the same issues as its Windows counterpart has (when you install lots of software, the list gets very long, and often almost unmanagable, especially when there’s a lot of Windows Update fluff in there).
“As far as i can think, the existing packaging in linux is much better then the windows-type installation.”
You have obviously never seen the struggle of a new Windows convert in this area and you are forgetting not everyone uses Linspire or Debian.
Mike Hearn wrote:
By changing the fundamental way we package software, we can support apt-get style user interfaces, […]
Hongli Lai wrote:
Having a repository for each distribution wastes manpower. […] And we have some plans to implement a repository-like interface ala apt-get/yum […]
It might sound like a foolish question but could you elaborate: It sounds af if you both are just talking about an apt-get like interface.
The value of a repository is the “division of labor”, isn’t it? I’m rather lucky that someone else does the work to implement security fixes so I don’t need to care about it.
Or are you talking about a (sort of) repository with autopackages ? For example, will I be able to update all my installed autopackages with a single click/command when the apt-get like interface is ready?
Zero install does a better job. With a bit more work on the administration tools side, it’s/will be much nicer. URI solve name collisions, plus make things much easier to find. No more you HAVE to be root to install stuff, though you can enforce that if you wish.
Additionally, before some moron says something uninformed about zero-install no it doesn’t have any of the problems you think it has, read over their architecture carefully, you don’t need to be online, you can install from local media, dial-up users are screwed either way, it’s more secure if not more so than RPMs and so on, and the cache doesn’t empty unless explicitly told to do so.
Lastly, apt is no where near scalable, the more packages the more people you need, it’s a linear scaling which is ridiculous; if the package is generated by those who make the program then you cut out a huge amount of effort and at least some of those people can be redirected to other work.
It might sound like a foolish question but could you elaborate: It sounds af if you both are just talking about an apt-get like interface.
Yes. As in a “type the name and get it” interface.
The value of a repository is the “division of labor”, isn’t it? I’m rather lucky that someone else does the work to implement security fixes so I don’t need to care about it.
The software authors do the fixes. The only question here is, how do those fixes get to you? There is no magic auto-update in autopackage at the moment. It could be added trivially, most of the code is already there.
Or are you talking about a (sort of) repository with autopackages ? For example, will I be able to update all my installed autopackages with a single click/command when the apt-get like interface is ready?
The plan is for an abstraction layer such that it’s possible to have all software no matter how it was installed provide auto-updates (assuming the software knows how to register). IE there’d be an RPM backend, an autopackage backend, and Loki setups could register themselves too.
autopackage4 will most likely be used for stuff like browsers, irc clients, p2p software and so on. not distro internals. so one will not see the big list of patches that you have in windows as you dont need those. you just run the distro updates at semiregular times and have it grab the latest rpms or dpgs. for those kinds of use the current system is perfect. autopackage is mostly designed so that you can have shareware/freeware style packages on webpages without worrying about what distro one is useing and so on…
I love autopackage as a supplemental installation method (I still like URPMI for official packages).
One suggestion for the developer, however (in case he reads this forum): in addition to the automated menu item generation, why not allow the user to set where the menu item will be added? It should be relatively easy to figure out what the menu tree looks like and allow the user to specify where the entry should go. This would be a plus for distros that have their own custom menu structure for GNOME/KDE (like Mandrake), or for users who like to play around with their menus (like me). Also, allowing the user to override the name of the menu entry would help for non-english installations.
Other than that, this new release works great, and I love the new uninstaller. Keep up the good work!
Good job
those kinds of use the current system is perfect. autopackage is mostly designed so that you can have shareware/freeware style packages on webpages without worrying about what distro one is useing and so on…
>
>
Now we know *THE REAL REASON WHY* certain people are hyping Garabge like autopackage, and it has *NOTHING* to with promoting the useage of either Free Software or Open Source.
“The value of a repository is the “division of labor”, isn’t it? I’m rather lucky that someone else does the work to implement security fixes so I don’t need to care about it.”
I hope you’re not suggesting people to distribute packages that contain their own patches for bugfixes and security fixes? Wouldn’t it be more efficient if those people send patches to you?
Saem:
“Zero install does a better job. With a bit more work on the administration tools side, it’s/will be much nicer. URI solve name collisions, plus make things much easier to find.”
It’s not that simple. Ever heard of Glibc 2.3 symbol dependancies? Symbol table collision? C++ ABI breakage? ZeroInstall doesn’t even try to solve low-level issues like that. Read the autopackage FAQ.
A nun, he moos:
“in addition to the automated menu item generation, why not allow the user to set where the menu item will be added?”
Not possible due to the current menu mess. GNOME 2.x implements vfolder menus. RedHat/Fedora GNOME partially implements the Freedesktop spec but it wasn’t applied upstream. Installing to ~/.gnome2/vfolders/application-info worked in GNOME <= 2.4 but not in >= 2.6. Category names depend on the .desktop file’s Category key and also the menu configuration file. KDE (at least <= 3.1) implements its own menu system (I don’t know whether that has changed in recent versions). Mandrake has its own menus. Debian has its own menus. Etc. etc.
We’ll at least have to wait until all desktops support the Freedesktop spec properly. Fortunately GNOME 2.10 will support it.
Rick James:
“autopackage is mostly designed so that you can have shareware/freeware style packages on webpages without worrying about what distro one is useing and so on…”
Are you serious??? Why would autopackage NOT benefit open source software? autopackage itself is open source. Every single component is open source. We encourage open development. We have developer documentation. We have end-user documentation. Etc. etc.
The Inkscape package is quite popular. It allows even people will slightly older distributions to run Inkscape without having to compile it (which can take hours if you’re on a slow machine). How’s that not benifical to Inkscape, a piece of open source software?
This is assuming the user knows the name of the software. The apt-get interface is good for experienced users, but not for new users.
Frontends which allow a user to search a repository exist, although its probably still too spartanic for new users. For example, afaik it doesn’t support something like a search for ‘i need type X program’ and ‘with type Y feature’.
With such repository, you know that when a user says ‘i run distribution X’, he/she runs a certain version which is probably patched/tuned for that distribution. With Autopackage, you don’t really know that, do you? How will Autopackage be consistent with the APT repository? Say a user installs Firefox 1.1 on Sarge via Autopackage. Is the package added in the APT database so that APT is aware of it? If then in Sarge, Firefox 1.1 is officially available then what will APT do? Install 1.1 (which possibly has patches or is tuned for Sarge) or use stay using the Autopackage one? What id it went the other way around? Seriously, i don’t get this part and i find it pretty important. What overrides what? It seems to me Autopackage wants to take away software packaging from distributions to developers; this meas that eventually APT databases (and similar) become obselete and that eventually Autopackage (the Firefox Autopackage for example) itself would contain the specific patches and tunings, but right now, thats not the case, right? So what happens right now? And, are users informed of this? (Couldn’t find this in the FAQ.)
If there is one thing I really miss from Windows, it is easy software installation and apt-get doesn’t cut it. (no license, no install options, not distributed etc.)
Ouch, you reminded me that this is in fact one of the things I hated about windows programs. You actually like the tedium of having to click next over and over again, and wade through options to keep programs from littering your system with icons and assorted cruft?
Not possible due to the current menu mess. GNOME 2.x implements vfolder menus. RedHat/Fedora GNOME partially implements the Freedesktop spec but it wasn’t applied upstream. Installing to ~/.gnome2/vfolders/application-info worked in GNOME <= 2.4 but not in >= 2.6. Category names depend on the .desktop file’s Category key and also the menu configuration file. KDE (at least <= 3.1) implements its own menu system (I don’t know whether that has changed in recent versions).
I agree, there are substantial differences between the various menu systems out there but…right now autopackage still manages to create a menu item (i.e when I installed autopackage-manager, it appeared in my own menu structure), so there must be some degree of menu awareness?
Perhaps the better idea would be to check if the system is compliant with a specific menu system (i.e. the Debian menu system, or the freedesktop specs) and in that specific case offer the player the possibility to customize the menu entry. Focussing on freedesktop would also be an incentive for distros to standardize upon a single menu method, which wouldn’t be a bad idea (hey, one can dream!)
Mandrake has its own menus. Debian has its own menus. Etc. etc.
AFAIK Mandrake uses the Debian system (i.e. files in /usr/lib/menu).
Do I gather that you’re one of the developers, then? If so, let me personally congratulate you for a great piece of software (oh, and ignore the trolls, they’re particularly nasty on this site…)
Inkscape uses autopackage for it’s cvs versions. Check it out, it’s awsome! I was really impressed when I used it the first time.
Keep up the great work guys!
Debian fully supports freedesktop.org menu systems. menu-xdg package generates freedesktop.org menu files based on Debian menu system.
See http://packages.debian.org/menu-xdg
I think this autopackage is important for folks wanting to keep their source closed. We do want linux to embrace commercial apps don’t we? In the end, it’s not the os but the apps that run on some common gui framework avail. for all machines out there in cyber world. I never had any problems with installing/uninstalling apps on my win98. Ofcourse I like ubuntu synaptic very much but this lag between app availability in repository and idea of keeping source closed cries for something like autopackage.
when i commented about atopackage being for freeware/shareware use i was useing it as a comparison to windows freeware/shareware sites where you just grab one install file and dont have to worry about distro or so on…
I know I shouldn’t give into trolls, but I can’t help myself.
Autopackage is a way to install third party software and does not, by itself, imply what kind of license the distributed software is released under.
Autopackage complements the open source philosophy very nicely because it give users choice, choice to install software that isn’t packaged for their distribution (or newer version is available), rather than compiling from source. How is that a bad thing?
And isn’t the freedom and the right to choose what linux and OS in general are all about. I sure hear that, or rather read that, a lot.
And for all obsessive trollers, it should be a medical condition by know (Obsessive Trolling Disorder?), get help, you need it.
There are a lot of things not answered by the FAQ. Here are two:
1: How will autopackage handle multiple platforms? At work we run linux on SuperSparc and UltraSparc IIi machines. How can you distribute binary packages until you know what compile-time flags I used? You can’t, because variations is compiler target flags will introduce a great deal of instability to a system.
2: How will autopackage deal with compile-options in other libraries? For example, when I install postfix I need to know if it was compiled with ipv6, pam, ldap, mysql, postgres, ssl, sasl, vda, mailwrapper, or mbox support. Would there be a package for each variation? (postfix-2.1.3-mbox-sasl, postfix-2.1.3-mbox-ldap-ipv6, etc.)
1: How will autopackage handle multiple platforms?
There is some preliminary support for multiple CPU architectures, as noted in the release announcement.
2: How will autopackage deal with compile-options in other libraries?
No. The idea is that the software is fixed so it does not require lots of compile time options, but rather adapts at runtime. For instance, right now the Gaim package requires gtkspell. This is awkward because not everybody has it, and some may prefer to use Gaim without spell checking support. The solution is called “relaytool”, which makes dlopen a lot easier to work with so the compiled binaries adapt to what is available at runtime.
postfix isn’t the sort of program autopackage is designed for anyway, really.
Hi, I’m having some problems in Gnome. I installed Gimp, Gaim, and Inkscape from autopackages, and they work great once installed – great job, Mike! However, I can only install them if I run the script from the terminal. Double-clicking on the .package in Nautilus doesn’t work, I get “There was an error launching the application”. Any ideas? Gnome 2.8/Gentoo.
Thanks!
“I’m having some problems in Gnome.”
Have you read this?
http://www.autopackage.org/docs/howto-install/
Yes. The executable bit is set if that’s what you mean.
OK, looks like I got it to work. I had to associate the .package files with sh. That way it works even without the executable bit set. Heh.
Ouch, you reminded me that this is in fact one of the things I hated about windows programs. You actually like the tedium of having to click next over and over again
Which is opposed to what, having to use some GUI package manager that has like 9,000+ packages listed, but just happens to be missing the one I’m looking for? So then I gotta find the IP address of the repository that has my app and hope it downloads all the dependencies needed, or worse yet, having to compile it from source and hope nothing blows up?
and wade through options to keep programs from littering your system with icons and assorted cruft?[/i]
Hmmm, littering the system with icons .. do you mean like putting items in the Start Menu where they’re supposed to be, something that, based on my observations, most Linux installers don’t do? So then I have to go hunting for the damn executable so I can create one manually. Eitehr that, or the program will be in the Start Menu in one DE, but will be missing entirely when I switch DE’s.
I mean, Linux package managers are great when they work, but when they don’t, once I go back into Windows, I’m just relieve that I don’t have to put up with all the bullshit. In that respect, Linux is kind of like babysitting somebody else’s kids – it’s fun to play with, but I wouldn’t want to have to deal with it full-time.
“Ouch, you reminded me that this is in fact one of the things I hated about windows programs. You actually like the tedium of having to click next over and over again”
You can check “Hide in the notification area and don’t ask questions” if you want. Try it out.