Slashdot Mirror
AutoPackaging for Linux
Isak Savo writes "The next generation packaging format for Linux has reached 1.0. With Autopackage officially declared stable, there is now an easy way for developers to create up to date, easy installable packages. There are lots of screenshots available including a flash demo of a package installation."
I'm a gentoo user as well, but I'm very excited by Autopackage. The whole reason many people use gentoo is b/c it is so easy to install software. The main problem with that system is that someone has to add it to the portage tree, and if it's not popular enough, it won't get in... with Autopackage you put the installation in the developers hands and you no longer have to rely on your distro to do it for you. I say use Portage/Apt/Whatever for your system/low-level programs and use autopackage for your higher level ones (Firefox, Gaim, GIMP, etc)...Autopackage could finally be the answer many Windows users have been waiting on to make the switch!
"A truly wise man realizes he knows nothing."
I suspect you are thinking of something like Conary. However ... that said, a distributed and decentralised package management system is what autopackage is all about. Autopackages can resolve dependencies in a manner that does not require large monolithic databases: the packages themselves know where to go to find their dependencies if they're missing (and in future they'll be able to use yum, apt-get etc as well just in case).
Basically the apt-get type model doesn't work too well once you start having say >50 repositories all together, as co-ordinating the overlaps becomes too much of a nightmare. A much less tightly coupled system works better, which is what we have here.
A few quick comment on your FAQ:
:-)
The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies.
OS X handles this at runtime. i.e. You can install the software, but the folder contents contain enough information for the OS to give you an error message when you run it. Usually this amounts to nothing more than "OS X 10.3 required!", but it could be more. FWIW, I think the lack of a "standard" set of OS services in Linux complicates this issue. Under OS X (and to a certain degree Windows), developers always know which libraries they can always depend on, and which ones they should bundle.
You'll note that bundled APIs on OS X and Windows tend not to duplicate each other across a given set of installed programs.
One obvious one is that there is no uninstall logic either, so the app never gets a chance to remove any config files it placed on the system.
This would be true on Linux, but it is NOT true on OS X. In OS X, the desktop integrates with the filesytem and learns via events when an application is added or deleted. This means that OS X users see file associations as soon as the program is added to the system, and they also see the deletion of those associations when the program is removed. It's all very seamless and prevents the dangling associations that plague Windows.
The OS X FS takes things one step further by storing file system IDs instead of path names for everything. This means that if I move my program from the Desktop to Applications, the associations will move with it. Similarly, if I have a file open and I move it, my file will save to the new location instead of the old one.
Another is that the app menus are largely determined by filing system structures. This means that it's hard to have separate menus for each user/different desktop environments without huge numbers of (manually maintained) symlinks.
1. An application menu IS just a bunch of glorified symlinks.
2. OS X handles this by having a system wide Applications folder for all users. If users wish to have private programs, they can drag them to their desktop or home folder.
3. The dock is the user's customized menu. The most commonly used apps are usually already there so that users don't have to hunt for them. If a user wants another app on his dock, he can drag it on there to create a shortcut. Shortcuts are deleted by dragging the icon off the dock or into the trash can.
What your FAQ should say is, "Unfortunately, the Linux design philosophy precludes the use of an appfolders system, as the services required to make such a system work are most likely unavailable on most installations."
Now with that cleared up, good job guys. I'm glad to see that someone is finally tackling my number one Linux gripe. (Check my Journal for more info.)
Javascript + Nintendo DSi = DSiCade