Username or EmailPassword
read various posts by debian folks. responses by mike hearn et al appear to be much hand-waving
They might have some points but consider this. By Slackware standards Debians package managment system is broken. Anything that forces package dependencies down your throat will in the end lead to disaster.
So what is more broken then DPKG or autopackage?
Which one works across the most distro's?
Since Autopackage is just another type of DPKG one would be as bad as the other.
Hmm, I'll bite. You don't provide links to support your words, but I know what it might be about (not only with Debian, but with other distros).
So why is Autopackage considered harmful by some people? The two basic reasons are security and system integrity. Let's discuss them both from common sense point of view.
The argument here is that "You shouldn't install software from random places in Internet". This specific reasons cited are threefold:
a) You don't trust developers themselves.
If this is indeed the case, why use their software at all? After all, if you think they can sneak spy- and malware in the stuff they release, do you honestly believe that this spy- and malware won't be carried over to the distro repository? No, distros don't do a comprehensive security audit of every package in a repository.
Moreover, let's not forget that we're speaking about open source software now (with regard to closed source, neither repository- or standalone installer-based model has any advantage). Do you use Windows? Do you use open source software for Windows downloaded from the developers' websites? Just how common are the cases when you got spy- or malware with that? Not very common I guess. Then shouldn't the reason for it be something else than the distribution model?
Conslusion: The problem is orthogonal to Autopackage.
b) You're afraid of a malicious hacker compromising a website.
This is a legitimate concern indeed. But couldn't the hacker compromise the whole repo as well? What's the difference then?
Conclusion: The problem is not specific to Autopackage.
c) The Autopackage installer is a shell script that's run as root and you give it complete control over your system.
Yes, the Autopackage installer is a shell script, but you don't have to install it as root if you don't trust the package provider (except the software that absolutely must be installed systemwide, in which case you can install it from source or distro repository, but then you'll have to deal with (a) and (b) cases anyway). You can refuse to give the Autopackage installer your root password, and then (provided the nature of the software allows it) it'll install the software in your home directory.
Conclusion: This is an Autopackage-specific problem, but Autopackage offers features that make it possible to mitigate it.
2. System integrity.
This boils down to "Thou shalt not install in /usr". While true IMO, the reason for this behavior of Autopackage is simply that distros don't properly support installation to /usr/local or /opt. This is about finding necessary libraries, putting menu entries in right places etc. However, this problem is not specific to Autopackage as such - a hypothetical LSB RPM package would suffer from it just as much. To reliably install a package with all necessary system integration, Autopackage is forced to use /usr. However, you can override it by specifying the prefix of your choice from the command line. It's just not guaranteed to work perfectly. And most often, you can install to /home!
The actual hazards of /usr installation are not that high. First, Autopackage installer will refuse to overwrite an installed RPM and will ask you to uninstall it first. Then, obviously, there is the risk that APT or a similar dependency resolution system will install another version of the software over the installed Autopackage. If you ask me, the policy of overwriting files quietly is questionable by itself to say the least, but let's forget about that for now. Remember that Autopackage is meant for installing application software, not separate libs or core system components. Therefore, the situation with installing a distro-packaged app over an autopackaged one will most likely be related to a dependency on this application - which doesn't happen that often. (The likely culprits here are large-scope metapackages like ubuntu-desktop.) But if a user did a systemwide install of an autopackaged app, he/she must be careful in order to not overwrite it afterwards (watch the dependencies and don't forget what you installed with AP!). All in all, I prefer /home as a desitnation.
And the last, but not the least: the effort that is needed from the distros to support /usr/local and /opt prefixes properly is miniscule (mostly steeing up some symlinks and environmemtal variables). But the reason they don't do it is very simple and sad. DISTRO MAKERS DON'T WANT USERS TO INSTALL THIRD PARTY SOFTWARE AT ALL. Period. You've probably heard many times that open source is all about choice and stuff, right? Well, if you ask distro makers, it must be wrong when it comes to software installation. Ironically, they seem to want to control your computer as tightly as Microsoft does! And this situation is not likely to find resolution any time soon... Luckily, there are workarounds for that, which is why Autopackage works NOW.
Even more interesting, the ideas of repositories, standalone installers and cross-distro packages don't even contradict to each other. Take Softpedia - a repository of standalone installers compatible with multiple versions of Windows OS. Nice, isn't it?
While true IMO, the reason for this behavior of Autopackage is simply that distros don't properly support installation to /usr/local or /opt.
Is there a list of distributions that do not support this?
And wouldn't it be possible to just add the paths instead of delivering your opponents the best excuse for not supporting it?