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."

Comments

The purpose of autopackage

[FooBarWidget]

No doubt lots of people will have all kinds of questions about autopackage, such as:
- "What idiots!! Another packaging format is the last thing we need!"
- "What's wrong with apt-get?"
- "Everybody should use Gentoo!"

Slashdotters are highly encouraged to read the autopackage FAQ! Our project has existed for over 2 years now, and many people have asked us those questions. In short: autopackage is not meant to replace RPM/DEB/apt-get/etc.

If you have more questions, feel free to come over at #autopackage at irc.freenode.net
We'll be glad to answer your questions

Re:The purpose of autopackage

[Screaming Lunatic]

All Your Packages Are Belong To Us [autopackage.org]

All Your Bandwidth Are Belong To Us.

Re:The purpose of autopackage

[Anonymous Coward]

Dammit! All i get is "emerge: there are no ebuilds to satisfy "autopackage".

Crap! *now* what do I do?!?!?

Re:The purpose of autopackage

[AKAImBatman]

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.) :-)

Some FAQ entries

[IamTheRealMike]

So much for sunsite having plenty of bandwidth and fast servers! Well, here are some select pieces from the FAQ:

# What is autopackage?

For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.

For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your userbase by allowing people with no native package to run your software within seconds.

# Is autopackage meant to replace RPM?

No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.

# Why a new format? Why do the RPMs I find on the net today only work on one distro?

There are a number of reasons, some obvious, some not so obvious. Let's take them one at a time:

• Dependency metadata: RPMs can have several types of dependencies, the most common being file deps and package deps. In file deps, the package depends on some other package providing that file. Depending on /bin/bash for a shell script is easy, as that file is in the same location with the same name on all systems. Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations. That means sometimes package dependencies are preferred. Unfortunately, there is no standard for naming packages, and distros give them different names, as well as splitting them into different sized pieces. Because of that, often dependency information has to be expressed in a distro-dependent way.
• RPM features: because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros or whatever, and then that RPM won't work properly on other distros.
• Binary portability: This one affects all binary packaging systems. A more detailed explanation of the problems faced can be found in Chapter 7 of the developer guide.
• Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database, it makes it hard to install them on distros like Gentoo even when they only use file deps. Similar problems arise if you compile things from source.

There are various reasons why a new format was created rather than changing RPM

Re:Some FAQ entries

[IamTheRealMike]

Why bother?

# What's wrong with centralized repositories, apt style?

The system of attempting to package everything the user of the distro might ever want is not scalable. By not scalable, we mean the way in which packages are created and stored in a central location, usually by separate people to those who made the software in the first place. There are several problems with this approach:

• 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 == 20 times 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 not 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.

# What's wrong with NeXT/MacOSX style appfolders?

One of the more memorable features of NeXT based systems like MacOS X or GNUstep is that applications do not have installers, but are contained within a single "appfolder", a special type of directory that contains everything the application needs. To install apps, you just drag them into a special Applications folder. To uninstall, drag them to the trash can. This is a beguilingly easy way of managing software, and it's a common conception that Linux should also adopt this mechanism. I'd like to explain why this isn't the approach that autopackage takes to software management.

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. Most operating systems are made up of many different components, that work together to make the computer work. Linux is no different, but due to the way in which it was developed, Linux has far more components and is far more "pluggable" than most other platforms. As such, the number of discrete components that must be managed is huge. Linux is different to what came before not only in this respect, but also because virtually all the components are freely available on the internet. Because of this, software often has large numbers of dependencies which must be satisfied for it to work correctly. Even simple programs often make use of many shar

Re:Some FAQ entries

[jxdxbx]

Also, there are no more DMG exploits. There is nothing wrong with having a few XML files around that belong to an application you no longer have, if it it really irks you, or if programs leave behind large caches, there are plenty of pieces of software that will delete preferences and caches that belong to software you no longer have.

Most applications shouldn't need to modify the OS to run, and for that minority that do, OS X still does have packages. This is how haxies and so forth work.

The only valid objection I've seen to bundles is the one about how a user shouldn't be able to install random software from the internet. This is a pretty good point, but I fail to see how that, even in a system that uses an apt repository, you would be able to prevent a user from downloading and installing some random RPM from a website. You would have to have a severely crippled OS.

Re:Some FAQ entries

[IamTheRealMike]

Are you sure about that? How do you know there are no more exploits? Do you have some power of clairvoyence nobody else does?

The thing that concerns me about the DMG exploits, is that they were caused by the fundamental design of the system not simple typos/poor coding practice. Having appfolders integrate with the system by registering file associations/URL handlers silently through the shell seems like the obvious way to handle this stuff in an "install free" environment, though really it's just doing the install at a later time. But it had unintended side effects which were devastating for security.

The problem is, to solve this you either have to go back to some explicit action integrating software with the system, or pile on more hacks to try and solve the security exploits. Apple chose both - Tiger boasts an improved installer, iTunes comes inside a package etc. But the approach they took with Safari reminds me of Internet Explorer: cover up a flawed technology like ActiveX with more and more hacks and security restrictions that somehow always managed to leak.

You are right that most applications should not need to modify the "system" to run. This is the principle behind authentication-less installation, which we only approximate on Linux with the install to $HOME feature in autopackage. Figuring out the exact set of permissions that are safe for installers to have and then enforcing them is somewhat tricky: both Windows and MacOS X are riddled with programs that demand the administrator password which implies that so far, nobody quite identified the sweet spot.

Re:Some FAQ entries

[Nailer]

"I fail to see how that, even in a system that uses an apt repository, you would be able to prevent a user from downloading and installing some random RPM from a website. You would have to have a severely crippled OS."

It's pretty simple: if the package isn't signed by someone you trust, refuse to install it. This has the been the behaviour in up2date since it was created, and yum does the same thing. I'd be very surprised if apt/get (at least on systems where package signing is expected) didn't do the same.

RPM itself, when used directly, currently throws up a warning if a package isn't signed by someone trusted, but (uunlike up2date / yum / etc) still installs it. This behavior may change in future tho.

Mirrordot

[Hachey]

it's about time there was a system to automatically put submitted links thorugh MirrorDot. This is a prime example; /.ed before 10 comments were posted. sheesh.


-----
Check out the Uncyclopedia.org :
The only wiki source for politically incorrect non-information about things like Kitten Huffing and Pong! the Movie !

Yes, we need this!!

[rice_burners_suck]

There aren't many replies to this story yet, but I can already see it: Lots of people are going to complain, "Why the fsck do we need yet another packaging solution?!?! We already have rpm, deb, tgz, blah blah blah..."

The reason is that most of these packaging solutions, while great for developers and those who want detailed knowledge of the inner workings of their systems, simply suck when given to mortal users.

And they don't handle a number of edge cases too well... What if you want different versions of some software to coexist on the same system? What if you want ten different versions of a library? Yes, these can all be handled by current stuff... but not very well. It's bad enough that when we install software here, we actually get the rpms or whatever and then re-package them ourselves to serve our needs.

A packaging solution that actually works is desperately needed.

Re:Yes, we need this!!

[Anonymous Coward]

I hate to say it, but...

It seems to me that {NeXT,Open,GNU}step-style apps are both good for developers, and great for mortal users. Drag an app (it's just a file) to your Applications folder, double-click it to run, drag it to the trash to delete. They also handle your "edge cases" (multiple installed versions) just fine.

They're actually quite a bit simpler for users because an app is just a file -- a first-class object in the system. You don't need a special program just to "install" and "uninstall" programs. You don't need ugly hacks like the "start menu" (Gnome or KDE's reimplementation of it). Users think an app should be a first-class object, and it's perfectly feasible, so as developers we should make that the case.

The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.

Re:Yes, we need this!!

[IamTheRealMike]

The autopackage FAQ has "what's wrong with NeXT/MacOSX style appfolders", but it seems to consist mostly of hand-waving and straw men. They don't seem to understand how NeXT/Mac apps work, e.g., w.r.t. linking.

Could you elaborate please? Of course it's possible to build a system that uses appfolders, NeXTStep is one, however:

• Doing that on Linux is hard, because of dependencies and the lack of a large platform. I'm not interested in theoretical systems, I'm interested in what I use which is Linux. I'm also not interested in MacOS X because I don't use that, and because it's proprietary which is totally not the way forward for our society.

• Linux isn't designed to allow appfolders easily. The freedesktop.org specs are oriented around the concept of "drop a file in this directory, update a cache". This works well for package managers, less well for appfolders. It's done that way for valid reasons: the menu system is designed with administrators, windows compatibility and internationalization in mind. The appfolders menu system isn't really designed per se, it's just a convention to put stuff in /Applications (and a shockingly large number of apps break if they aren't in /Applications).

• The issues with linking etc are well known. Yes I understand how MacOS X linking works, that includes how frameworks work and also the weak linkage Apple use. Before suggesting we don't understand linking how about reviewing things like apbuild and relaytool. Nonetheless, new libraries are manufacturered at a quite astonishing rate on Linux: the openness lends itself to massive and extremely fine grained code reuse. That means we can't just rely on having a bigass platform, though one would be nice. Dep resolution is still important simply to prevent your OS becoming totally obsolete within a year.

The only person who has really done serious work with appfolders on Linux is Thomas Leonard, an extremely smart man who was behind the ROX desktop. Note that appfolders aren't a Mac or NeXT invention, they were done by RISC OS back when I was a wee kid.

As Thomas found out, dependencies are kind of a tricky problem with appfolders. His solution was ZeroInstall, a very nice piece of work I must say. However it had issues, as software often does, and now he is designing something called the "Injector". This has quite a few concepts similar to autopackage, namely management of interfaces and dependencies. So in the process of "fixing" appfolders to have all the features people wanted, he ended up with something that vaguely resembles systems like autopackage and apt-get. Note: that doesn't mean to imply that the Injector is useless or anything, it's not and has some good ideas. I encourage people to check it out!

Just be aware that appfolders tend to evolve into installers eventually. They did on DOS, RISC OS, and of course on MacOS X as well (iTunes comes in an installer and it's not the only one ....)

Wrong Paradigm

[user9918277462]

I've said it before and I'll say it again: The Windows model of acquiring and running software from a large number of random third parties is broken. It is fundamentally unsafe and, frankly, archaic in 2005. We do not trade 5.25" floppy disks with BASIC games on them, and we certainly shouldn't be downloading self-extracting installers from sketchy websites anymore, regardless of OS.

The current Linux model of distros integrating and authenticating software from upstream authors helps ensure the security of the userbase as well as providing installation ease of use. This is something we should be proud of rather than trying to imitate the technically inferior competition.

Re:Wrong Paradigm

[Steven Edwards]

If the Windows Paradigm was broken people would not use Windows. Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example. Windows security in most regards does suck but packaging is one of the few things Windows does right. You do know you can sign a package in Windows right? Vendor certificates work, just install any packages from Microsoft or from any other major third party vendor.

I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.

Re:Wrong Paradigm

[karmaflux]

Bittorrent calls you a liar, buddy. We trade 5.25" floppies in a metaphorical sense constantly. When I develop a program that takes random input and outputs Frank & Earnest cartoons, I don't want to have to wait for some Board of Linux Usage Oversight to give my 5k perl script the Stamp of Approval.

Nobody's trying to copy the Windows paradigm with autopackage. What they're trying to do is break down that barrier to cross-distribution software releasing. Your average desktop user does not want to compile software. Dropping to a terminal, cd pathtoapp, tar -jxvf whatever.tar.gz, cd newpath, ./configure; make; make install is too much shit for a user -- and then how to uninstall? Keep the source directory there forever?

"If they can't compile they should run Windows" is a stupid, backwards attitude, and autopackage is trying to fix it. Relying on upstream content providers is dangerous -- what happens when you disagree with your upstream provider? You have to switch distributions? Pat recently dropped Gnome support for Slackware -- I still run gnome. I do it with a third-party package from dropline. Is that broken? No.

The way to fix the problems you describe is to educate users, not to remove their usage priveleges. Teach people not to install untrusted software -- and teach them how to tell what software to trust! Don't just slap their hand and yell NO.

Re:Wrong Paradigm

[labratuk]

If the Windows Paradigm was broken people would not use Windows.

I'll tell you this now, the packaging system is not the factor that people base their decisions to run windows on.

Yes there are some things about Windows that suck but MSI and InstallShield installers are not a example.

When you are installing from installshield, you're basically saying: 'Hello random executable from the internet (even if you are signed by someone), here, overwrite any of my libraries you'd like, with whatever obscure or customised version you want. Oh, and while you're at it, do whatever you want to my registry...'

I guess you would only be happy if we just pulled everything down from SVN/CVS and built from source.

That's a strawman attack. He didn't say anything like that - in fact it's the complete opposite of what he was arguing.

Re:Wrong Paradigm

[ferratus]

I don't think MSI or InstallShields (or any other Windows installer for that matter) are broken, but I do agree with the parent post in that the way to *get* the software on windows is not all that good.

If there's one thing I love about Linux is the way I can download/install a software using a single command (or a GUI tool) in most distros.

Even Gentoo, not exactly regarded as the most user friendly distro, allows one to download & install a software by doing:

emerge XYZ

That's it. Same goes for Mandrake, Debian, Fedora, etc. End-user distros like Linspire even go further by allowing you to browse through all available software, look up the description and then perform a "one-click" install.

I think that's great, and a whole lot better than the windows (and mac os x) alternative where you have to look for software on the web, try to see if they contain malware, download them, run the installer, etc.

One of the advantage of the system is that the upstream provider (i.e. usually your distro) checks the package for validity. The packages you download won't contain virii or spyware (even if those were to exist on Linux) because the provider would likely not allow them...something MS would certainly do if they controlled the software ppl are downloading.

I know some packages are hard to install (Gnome for example) but for the most part, I feel software installation is a lot easier on Linux than on Windows, unless you go the CVS/SVN route and compile everything yourself.

At least on Mac OS X, you usually simply drag and drop the Application in the Applications folder and that's it. While not perfect, it's a whole lot better than Windows.

Re:nextgen already here: emerge

[ArbitraryConstant]

Developers want to be able to release packages that work on all the Linuxes, not just Gentoo. Not everyone wants to make the fast updates/reliability tradeoff necessary to use Gentoo.

For more information on autopackage...

[mp3phish]

I have been following autopackage for a while now.. It looks promising. This release will be the test to see if anybody will take it seriously (I hope so). Autopackage brings some really cool features to the table:

• Frontends to different windowing and desktop systems.
• Able to resolve dependancies even if you installed other software through the source, or with RPM or DEB
• You will be able to download one package and install it on several different distributions.

Essentially, this will be as flexible as tarballs, only they will install easilly, and have clean upgrade paths and uninstall paths. With clean dependancy resolution. It sounds too good to be true, but you can only know it if you try it.

Here is the sourceforge link with some more info and downloading.

Re:Where does everything get autopackaged to?

[Abcd1234]

Umm, that's what the Linux Standard Base is for. Blame the distro makers and packagers for not following it. After all, the LSB has been out for a *long* time...

DIE FANBOY MODS

[Anonymous Coward]

Official Gentoo-Linux-Zealot translator-o-matic

Gentoo Linux is an interesting new distribution with some great features. Unfortunately, it has attracted a large number of clueless wannabes who absolutely MUST advocate Gentoo at every opportunity. Let's look at the language of these zealots, and find out what it really means...

"Gentoo makes me so much more productive."
"Although I can't use the box at the moment because it's compiling something, as it will be for the next five days, it gives me more time to check out the latest USE flags and potentially unstable optimisation settings."

"Gentoo is more in the spirit of open source!"
"Apart from Hello World in Pascal at school, I've never written a single program in my life or contributed to an open source project, yet staring at endless streams of GCC output whizzing by somehow helps me contribute to international freedom."

"I use Gentoo because it's more like the BSDs."
"Last month I tried to install FreeBSD on a well-supported machine, but the text-based installer scared me off. I've never used a BSD, but the guys on Slashdot say that it's l33t though, so surely I must be for using Gentoo."

"Heh, my system is soooo much faster after installing Gentoo."
"I've spent hours recompiling Fetchmail, X-Chat, gEdit and thousands of other programs which spend 99% of their time waiting for user input. Even though only the kernel and glibc make a significant difference with optimisations, and RPMs and .debs can be rebuilt with a handful of commands, my box MUST be faster. It's nothing to do with the fact that I've disabled all startup services and I'm running BlackBox instead of GNOME or KDE."

"...my Gentoo Linux workstation..."
"...my overclocked AMD eMachines box from PC World, and apart from the third-grade made-to-break components and dodgy fan..."

"You Red Hat guys must get sick of dependency hell..."
"I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH .rpms together on the command line, and that problems hardly ever occur if one uses proper Red Hat packages instead of mixing SuSE, Mandrake and Joe's Linux packages together (which the system wasn't designed for)."

"All the other distros are soooo out of date."
"Constantly upgrading to the latest bleeding-edge untested software makes me more productive. Never mind the extensive testing and patching that Debian and Red Hat perform on their packages; I've just emerged the latest GNOME beta snapshot and compiled with -09 -fomit-instructions, and it only crashes once every few hours."

"Let's face it, Gentoo is the future."
"OK, so no serious business is going to even consider Gentoo in the near future, and even with proper support and QA in place, it'll still eat up far too much of a company's valuable time. But this guy I met on #animepr0n is now using it, so it must be growing!"

Please let non-root people install

[Anonymous Coward]

The only thing I'd like to see in a package manager is to allow non-root users to install software (perhaps under $HOME ; perhaps under /usr/local if they're members of the group local).

It's absurd that you need to enter a root password to do something as simple as install a user-space program - and it's absurd that package mangers only support dependancy checking for stuff installed in the main system directories.

At work, the main directories (/usr, /bin, etc) can only be accessed by the IT guys; but every department has a directory ("/usr/department/engineering", for example) of that memebers of that group can install software in. We have a newer version of Perl in ours. It really sucks that package managers can't help deal with the dependancies in an environmennt like this.

Re:Please let non-root people install

[stefanlasiewski]

The only thing I'd like to see in a package manager is to allow non-root users to install software

Check out the Flash demo. They actually demonstrate that capability-- the application installs packages under $HOME/.local/lib $HOME/.local/share, etc. I dislike cluttering $HOME with $HOME/lib, $HOME/share, $HOME/man, etc. -- installing these pieces under a dot directory to keep them hidden & organized is a great idea.

But I am also curious about allowing groups to install software under /usr/local or /usr/department .

Re:Please let non-root people install

[hawk]

Err, are there really package systems that *don't* let you do this?

Under the FreeBSD ports system, you simply set $PREFIX to wherever you want things to happen. While this is probably not obvious to grandma, it would just come to a script to

1) add $HOME/.programs to the relevant paths
2) add the "mypackage" script to $HOME/.programs/bin which sets $PREFIX and passess the rest of the argments.

It's been a few years since I've used dpkg, but I'm pretty sure that it had similar options, and I always assumed that rpms could do something similar.

hawk

Re:Aren't there enough

[FooBarWidget]

I knew someone would say that. Read our FAQ. Mike posted a part of it below. Please read our website for the full FAQ once the Slashdotting is over.
And we'll be available at #autopackage at irc.freenode.net if you have questions.

Mirror of the autopackage website

[FooBarWidget]

Mike setup a mirror of the autopackage website! It's here. The FAQ is also available on that mirror.

Re:Where does everything get autopackaged to?

[FooBarWidget]

By default, autopackage either installs to /usr or to $HOME (depending on what the user wants). If you really want it to use another prefix, you still can. The reason we use /usr instead of /usr/local is because there are many broken distributions that don't setup paths for /usr/local correctly. And /usr is the standard for many/most distributions.

There's a mirror of the autopackage website's information here.

Re:nextgen already here: emerge

[ZephyrXero]

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!

Re:Aren't there enough

[diegocgteleline.es]

yes, but that's not the main problem IMO. Package formats are often tought as the number 1 offender when it comes to inter-distro compatibility, but that's not the main problem. The main problem is that package mainteinance happens at distro-level, instead of developer-level. What we need is to move as much mainteinance work to the developers. It's the number 1 cause of problems: A package in debian may require "libfoo", but in fedora it may depend on "foo" or "foo+randomstring". If all those things would be done at developer level, they'd be more coherent, and inter-distro compatibility would be greater. Package format would be irrelevant.

And this is why autopackage is great. It doesn't tries to replace apt/rpm/gentoo, it just tries to be a good way of distributing software, and encourages developers to create their own "autopackage packages" so they work in every distro

Mirrordot of Flash

[vectorian798]

Flash Demo Screenshots

I have to say this is like a godsave for linux. Most layusers will want some easy installation like this instead of using something like Yum (even if it is a GUI front-end to yum like GYUM). This is one giant step towards a viable desktop linux - and I believe that it isn't a replacement for apt/yum/[INSERT YOUR FLAVOR HERE] but uses them under the hood.

Before everyone starts bashing it and says that apt or emerge or whatever they use is the way to go, seriously think about it - one click installation, from a FRIENDLY user-interface, and easy to manage system for installing and uninstalling programs. Now if this were part of the base install on many distributions and some sort of standard was established (seriously, we need standards) I can probably convince my scared-of-Linux-because-it-is-hardcore friends to actually try Linux out.

One Autopackage...

[dotslashdot]

One format to rule them all, One format to find them One format to bring them all and in the package bind them...

Re:Be like OSX

[MsGeek]

Here's how you fix dependencies in Debian:

#apt-get update
#apt-get dist-upgrade

Badabingbadabangbadaboom. It's done. Happy days are here again.

Re:nextgen already here: emerge

[ArbitraryConstant]

Jesus Gentoo fanbois can be annoying. For some reason, unlike the users of every other distro, some Gentoo users think everyone would be happier with the decision they've made for themselves.

Some people like Gentoo, but some people have serious issues with it. emerge is a decent package manager, but it's attached to a distro that conservative users aren't going to touch. The more conservative distros have package managers that their users are already perfectly happy with, so it's unlikely to be used anywhere else.

Conflicts with existing package managers

[jesterzog]

I'm presently running Debian. I've briefly played with making my own .deb files so I'd be able to install some of my own things without necessarily completely losing track of everywhere they were scattered. With all of the extra meta files that need editing, the source packages versus binary packages, and everything else, though, the whole process of designing a .deb package looked a bit too structured and complicated for me to bother learning about... at least within the time I was prepared to spend.

If AutoPackage has a straightforward way to generate a simple package, such as from a tar.gz file, I might find it very helpful. What I'm wondering about, though, is how bad does it get when two package managers conflict? eg. Apt and AutoPackage might end up trying to control the same file, get mixed up between what manager is providing a particular dependency (particularly if Apt tries to grab a package that AutoPackage has already installed), or whatever else.

It also sounds a bit of extra work having two sets of commands to manage packages on one system, so ideally (in my world), I guess AutoPackage would wrap around Apt or whatever other manager, and invoke it when appropriate. Does AutoPackage just fight for control when there are conflicts, or does it integrate with other package managers nicely?

The server seems to be very slashdotted right now, so I can't do much reading up on it. Does this sort of conflict thing turn out to be much of a problem?

Re:Conflicts with existing package managers

[FooBarWidget]

Autopackage is meant to be an add-on that coexists with your native package manager. It's not meant to replace anything. And the conflicts you're talking about will only occur if you try to install the same deb and autopackage on purpose.
For post-1.0, native package manager integration is on our todo list.

Re:nextgen already here: emerge

[ZephyrXero]

That's fine for advanced users who can handle the command line but what about the remaining 97% of the world?

I will not use it

[houghi]

I am a SUSE user and yet have to find a program that does not have an rpm I can use. If the writer does not make an rpm, with running checkinstall, I doubt he will be using autopackage.

Using this would mean I need to have TWO things to use. One being Yast, the other being autopackage. Next somebody else does the same thing in a slightely different way and soon I will have a packager for every program I own.

Also its use is slightly more complicated then just doing rpm -Uvh (or for me yast -i, or rightclick on in Konquror)

As an extra, on the install site is says to chmod +x the files. Why not have the binaries already as chmod+x downloadable and if not, why do you need to do it on the commandline when 'sh file.package' works just as well.

Another disadvatage is the fact that houghi@penne it needs some extra code:

houghi@penne : sh inkscape-0.41-2.x86.package

The installation of this software requires some additional support
code to be installed.

Connecting to autopackage.org[130.225.247.90]:80... connected.
HTTP request sent, awaiting response...

Mmm. I can not install, because the site is down.

Did a search on rpm.bone.net on inkscape and copied the link and did 'rpm -Uvh ftp://link

Now what do you think I will use in the future?

Re:Be like OSX

[GoldDog]

hahahahahaahhahahaha
hahaha
hahahahahahaha *gasp* HAAAAAAAAAHHAHAHa

Now Debian is my favourite distro by far but I'm never gonna pretend that the package system is solid. Having way to many times been in the position where some little thing breaks and dpkg and apt just choke totally (to the point where I can't install something because I some package is broken and I can't uninstall that package because the damned uninstall-script needs something installed first).

The long and short of it is No, that's not how you "fix" dependencies in Debian. A lot of editing obscure files, handrolling temp replacement packages and so much swearing I need to put a parental advisory sticker outside my appartment is.

The idea of packages is bad.

[jxdxbx]

For distributing user applications, at least.

There is no earthly reason why a GUI application should scatter files hither and yon across a hard drive, and why installing a program should require some package or installer or whatever.
I cannot believe the hassle that I have to go through to install software on my Linux box as opposed to my Mac.

An OS X application consists of one file--- really a bundle. It is a directory that acts like a single executable file. Everything it needs to run that is not part of the basic OS X setup is in that file.

You don't even need to install the application. You can just run it from its compressed disk image that is still sitting in your downloads directory, if you like. Or you can copy it to your hard drive wherever you like. When you tire of it, you delete it.

Now, "Linux" is not capable of doing this because no one runs just Linux. But there is no reason why, say, Gnome apps can't be distributed this way. If there are technical issues in the way, they need to be resolved. Because the OS X way is better that the Linux and the Windows methods, and ought to be copied.

(ps: I do know that Unix programs are often installed via packages in OS X, as well as software that for whatever reason needs to modify the OS. But these are very rare and approached warily by seasoned OS X users.)

Re:BackPackage

[IamTheRealMike]

The really big leap in backends would be a distributed repository.

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.

Re:That's right. apt-get works.

[IamTheRealMike]

Having applications (as opposed to libraries) installed outside of apt doesn't break anything as they aren't dependencies of things.

Re:I don't know about this

[Master of Transhuman]

"To me it seems like anything that makes it easy for users to install random software off the internet to be a REALLY BAD THING."

This is hardly the point of the project.

The point of the project is to eliminate problems for developers in packaging their software to be able to run across distros.

The fact that it makes it easier to relieve dependency hell is a bonus for those users who want packages not included in their distro.

Anybody who says EVERYTHING they'll ever need is included in their distro is just being a troll. Because it simply is not possible that ANY distro is "finished." And a lot of people don't want to wait months until something they want shows up in a repository.

If Windows did that, everybody would still be using DOS.

Finally, the notion that it is somehow "evil" to install software from the Net is just stupid. The Net exists to distribute information - and programs are part of that.

Practically everything I use on the Windows side of my machine was downloaded off some Web site or another - and I have several gigs of stuff on my Linux side to explore yet which also has the same origin.

And I have NEVER had a spyware/virus/trojan problem from such software. (Although I have had software that simply screwed up the machine due to stupid programming.)

Users get spyware and other crap from stupid, pointless little programs offered by commercial entities because the user acts like a kid in a candy store when offered something "free". If the users really knew what freeware was about and where to get anything they need, they would be less likely to do stupid stuff like downloading a calendar program loaded with spyware.

While it is true that CORPORATE users should be restricted from downloading any damn thing they see (unless it has a productivity purpose), home users certainly should not be.

Your solution smacks of the paternalism I hate about Windows. You want your distro to control your machine just as much as Gates wants to control Windows users.

Sorry - not acceptable.

Re:I don't know about this

[imkonen]

" There is no software I need that is not included with my distro"

Sorry if this sounds insulting, but your attitude seems really narrow-minded and short sighted. The whole reason the computer is such an incredibly useful tool is that it is so flexible and extendable. YOU might manage to get everything you need out of the software included in your distro, but do you really expect the big distros to anticipate every single need of every single user? A lot of people who are not computer experts have specific application needs that the vast majority of users don't share. Should a good distro include a version of GAMESS just because I want to do a theoretical chemistry calculation? Or maybe the people who make distros should assume (correctly) that if I am one of the .0001% of computer users who would want to use that program, I should just go download it myself?

"This may sound elitist of me, but if you can't figure out how to do it now, you probably aren't capable of making that sort of decision."

Yes, you sound incredibly elitist, as if it is impossible to be smart and NOT a computer expert. There is a big difference between knowing enough about one's Linux distro to install a program and having enough common sense to find programs on the internet with minimal risk of installing malware. If I google search for software that simulates microwave spectra of asymmetric top molecules (and by the way there are quite a few) what are the odds I'm going to find spyware masking itself as what I'm looking for?

Re:Aren't there enough

[diegocgteleline.es]

Woah woah. Let me just stop and laugh for a moment. You're telling me that random developer X can do a better job of making a package than the people who develop the friggin' distro? Are you kidding??

They won't do "packaging" better, simply it will be better. The developer of project foo may say: "foo version 2.15-b depends on project bar version 1.1 to run properly", and everyone would follow it. Distros still could package themselves in a different way but that won't bee too common, and at that point people may tell "hey, your fedora package don't works properly in debian". My point is that a common package format

WONT SOLVE ANYTHING. Autopackage doesn't solve anything because it's a better format, but because it has a different philosophy. It doesn't matter how good are deb or rpm - they will NEVER work in another distro just because of their philoshopie

Re:... is completely unclear

[Nailer]

Actually, I'll bite on some of his later answers, where, unlike the one to the previous question. he does go through some specific issues he has 'with RPM/Dpkg':

"Other dependencies are not so simple, there is no file that reliably expresses the dependency, or the file could be in multiple locations"

Yes, that's what virtual dependencies / capabilities in both rpm and dpkg provide. As for files moving around, that's what the FHS is for. Got a

But in reality, you don't encounter this scenerio untill you install rpms/ debs on another distro. Big deal: binary packages will always be built against specific library versions. Autopackage doesn't solve that.

"because RPM is, at the end of the day, a tool to help distro makers, they sometimes add new macros and features to it and then use them in their specfiles. People want proper integration of course, so they use Mandrake specific macros "

That's a human problem. You can't fix it with technology. Taking away the ability to have custom macros is a bad thing. Encouraging proper behavior is a better thing.

"Bad interactions with source code: because the current versions of RPM don't check the system directly, they only check a database"

You don't mean bad interaction with source code. Installing from source works fine, provided you know how to make install you can easily reate an RPM of most autoconf apps in about 2 minutes.

You mean bad interaction with non-packaged software. Again, that's a human issue, but one that's been solved better and better over time. Both OSS projects and proprietary vendors including Adobe's, BEAs, Macromedia etc. all release properly packaged binaries.

And frankly, I like having a database. I want to be able to find out what package was responsible for installing a file, and a URL where I can get a new version of the software. I like having a checksum of all my files at install time, so I can see if they've changed later. All of which autopackage doesn't do.

I don't like anything that encourages people to install unsigned applications from the internet, which autopackage does.

"a dependency does not encode any information on where to find it"

Yes, Great they kept that shit out of the dependency isn't it? Because what provides that capability isn't determined by the software. My app needs a webserver. That could be thhtpd, Apache httpd, Roxen, or whatever else. Rather than specifying what package provides that dependency, they simply list the depency. Three of my available packages say they provide a webserver capability. When a new webserver comes out, it will say it provides that capability too. Without requiring a new package of the thing that wants a webserver. Brilliant stuff!