"Right there is one of the issues that makes autopackage such a hard sell."
Did you miss the bit in which I said "As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed." ?
But let us go back to the problem. The user has two choices: 1. Install an autopackage of FooBar 2005 (latest version), which overwrites the existing copy. -OR- 2. Not being able to install at all, and having to wait 3 months for a native package to appear.
Which one do you think is the better choice for the average user? And again, "As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed."
"If/usr/local/ support is horked on a distro, suggestion would be to actually get it fixed rather then doing a kludge ('It works now' logic is dodging the fact that the pkg manager relationship here is non existant, thus it's a kludge)."
You are correct. But the problem is, distributions refuse to fix/usr/local support! We've asked them. They all refused to do anything about it. Some of them even say that they've explicitly b0rked/usr/local support because they don't want people to install to/usr/local.
The fire marshal is specialized in extinguishing fires. They are not specialized in other areas. Likewise, the distro guys are specialized in packaging their *own* distros, but not inter-distribution packaging. You still shouldn't let them do the thinking for you.
Autopackage is used by high-profile projects like AbiWord, Inkscape and Gaim. Upstream trusts us. What do you think that means?
"Again, we know that and as we just said the fact that autopackage doesn't allow seperate privilages between the package and the package installer is a _bug_ not a _feature_."
Does RPM/DEB provide that seperation? Last time I checked (today), RPMs *must* be installed as root. As the preinstall and postinstall RPM scripts can do whatever they want, including rm -rf/. I also haven't found a way to install DEBs as non-root (on Debian and Ubuntu). Can dpkg prevent DEBs from wreaking havoc in pre- and postinstall scripts?
Autopackage is *open source*. If you don't trust us, you can inspect the source code. It's there, readable with vi, emacs, less or whatever your favorite text viewer is. You can easily search the header and scripts for trojans. Scripts aren't dangerous by themselves. Scripts are dangerous if they contain dangerous code. So if there is no dangerous code then what's the problem?
We're being used by high-profile projects like Gaim, AbiWord and Inkscape. Upstream trusts us. That should say something, right?
"end result is the support for when stuff breaks falls on the distros head."
No. People are supposed to report bugs to us or to the upstream developers.
"What the user wants is something the distro tries to address- just because autopackage comes along and states their desktop orientated, in no way makes them better, nor worse then the distro's focus of full integration and packaging of software."
You are correct. But the fact is, distros can't package everything. If you look at Linux forums you'll see that people often complains about: - My package is not in the repository. - My package is in the repository but isn't the latest version. - The package in the repository is broken. (*cough* Fedora Extras galeon 1.3 *cough*) And this is where autopackage jumps in. They provide an extra choice for people who aren't satisfied with the native package management system.
The reason why we allow root installs is because there are people who want to install software system-wide. And some things just work better when you install to/usr as root (unfortunately not all desktop environments fully support locating resources in $HOME). And this is also why we *ask* the user whether he wants to enter the root password.
All the complaints seem to come from power users who don't like the idea of a new packaging format. The inexperienced Linux users seem to love us, as can be seen from the feedback we get from them.
"Also, maybe autopackage has been updated since I last used it, but I was only prompted once for a root password. Subsequent package installations went straight to/.local without asking."
Sounds like a bug. Are you using Ubuntu? It might be related to sudo.
"If you're really not interested in actually solving a problem, just say so."
I don't say so, which means I AM interested in solving the problem.
"Existing packaging systems Just Work for Linux PPC. Yours doesn't. How is that possibly an improvement?"
Autopackage's goal is not to be "better" than RPM/DEB. Autopackage's goal is not to surpass current packaging systems in every way possible. Autopackage is not supposed to completely replace RPM/DEB.
Let us go back to defining the problem. The problem is: software installation on Linux is too hard for the average user. And what do those users use? x86 Linux! Really, look at the numbers. Browse some Linux forums, mailing lists, newsgroups, etc. Almost every time people complain about software installation on Linux, it's about x86 Linux. Have you ever heard of people complaining about software installation on PPC Linux? I don't. The people who want a friendly OS on PPC all use MacOS X. Have you ever seen people trying to convert Mac users to Linux? I don't. Have you ever seen people trying to convert Windows users to Linux? I have, many times!
In other words: the problem just doesn't exist (or is too small) on Linux PPC, or people would complain about it. The software installation problem is pretty much unique to x86 Linux, as that's where the majority of the users are! And there's the real reason. 99.9% of the problem is on x86 Linux, so logically it only makes sense to focus on x86 Linux.
"I really don't see why this isn't the default way to do autopackage."
I don't know what you mean, as every time you install an autopackage, it asks you to enter the root password. If you want it to install to ~/.local, then just click "No Password" in that dialog. What is the problem?
"That seems like a rather large bit of hubris considering binary distros were already dealing with binary compatibility issues, long before autopackage existed."
I mean inter-distribution binary compatibility issues. Do distributions deal with that? So far I haven't seen any distribution who cares about being able to run their binaries on other distributions, or vice-versa. If you know one please let me know and I'll applaud them.
"it's definetly not unforseeable that your package will require a version of gtk that is slightly different from the version that is installed upon the system."
You are correct. We don't claim to solve *all* problems, but we do solve a great portion of them. We have received a lot of positive user feedback.
"[Worse, if it has the same soname but different API or ABI.]"
Then that library is utterly broken and must be fixed. We actively encourage developers to adhere to libtool version.
"This "solution" is to double or trebble the size of the packages distributed by compiling them for every possible ABI incompatible version."
Right now, there are only two major ABIs: the GCC 3.2 and the GCC 3.4 ABI. Nobody (at least, nobody who cares about the desktop) uses the pre-GCC 3.2 ABI these days. And it won't double the size. We use binary diffs, and this saves a lot of space (roughly 70%-90%, depending on the binary). And a major part of desktop apps usually consists of data files; those are not duplicated. Autopackage 1.2 also features LZMA compression, which offers better compression than even bzip2 (which is used by RPM AFAIK; not sure about DEB).
Do you know a better solution though? At least this one works. Making it work is more important than making it perfect. Frankly, to truly solve the problems, the Linux community has to start caring more about binary compatibility. But from what I understand, you seem to have already given up on that, by claiming that it's not possible to create portable binaries. But we have to start *somewhere*, don't we? The solutions may not be optimal, but at least they work.
The reason we don't deal with tarballs is because: 1. No desktop integration. Tarballs don't install menu items and icons for you to the right place. We do. We go into great length to deal with the myrads of different menu systems. 2. Binary compatibility. Tarballs are just that - tarballs. Part of the autopackage is research about binary compatibility. We figure out why binaries don't work on other distros, and try to fix that. Without a solution to binary compatibility problems, using any format is meaningless.
"And how about that button in the Window manager? Doubt Autopackage can handle that detail, as I use fvwm2."
You are correct, we don't support fvwm. But honestly: how many people use fvwm? More importantly: how many average users use fvwm? A simple cost/gain calculation reveals that we should focus on GNOME/KDE support instead. We intend to solve real-world problems with software installation on the desktop. We aren't trying to support every window manager out there, we aren't trying to replace RPM/DEB, we are trying to solve user-visible real-world desktop software installation problems.
"And you still have to solve this problem when I distribute an epoll using application to a system using a glibc that doesn't have the epoll symbol. And this is such an obvious UI issue, I dearly hope you have a better example than this for why you screwed the pooch."
In this case, yes. But usually this doesn't happen. Remember that autopackage targets desktop applications: i.e. the stuff that average users cares about, not server applications. I don't know many desktop applications that use epoll or other OS-specific APIs - they usually use portable APIs like the GNOME/KDE stack.
But, even if you must use epoll, there's still a way to solve that. As autopackage installation scripts are script-based, you can just do this: 1. Compile two binaries: one with epoll support, and one without (falls back to regular poll). 2. Put both of them in your autopackage. 3. Autodetect at runtime whether glibc and the kernel supports epoll. 4. Install correct binary. It's more work, but it's possible. And it sure makes things a lot easier for the average user. In fact we use a similar method to solve the C++ ABI breakage problem.
"you have X provided by you and Y provided by the distribution"
This situation is currently impossible, as the native package manager will think that X isn't even installed, simply because it isn't in its database. For example, if you install gtk from source, then install the Gaim RPM/DEB, then RPM/DEB will complain that gtk is not installed even though it is.
"With aribtrary binary applications this is somewhat muddier, but there is still a deliniation between trusting the package and trusting the package installer (the later of which likely needs more privilages)."
Not so with autopackage. You can run autopackages as user and install to ~/.local. You don't have to give it root access if you don't want to. And as autopackage is open source, you can check the source code for trojans. Autopackages are tarballs with a shell script header. Anyone can check the shell scripts for trojans.
"For instance "conary" is one of the newer package management ideas, and to them packages are basically just collections of files which are tagged (Ie. doc/bin/shared-library). Installing/removing a package has basically zero security concerns."
I'm not familiar with Conary, but do they take care of desktop integration stuff like menu items and icons? What about things like updating the icon cache? (If you don't do that some icons won't appear in the GNOME menu) Or the MIME cache?
And does Conary research inter-distribution binary compatibility? As far as I know we are the only group that have good knowledge about binary compatibility problems and actively try to solve them. Without a solution for binary compatibility problems, you cannot make inter-distribution packages no matter what packaging system you use.
"So autopackage will stomp all over the files installed by the distribution by default."
No. It will only do that if you want it to do that. Install to $HOME if you're paranoid, or tweak the settings to not default to/usr. - There's a good reason why we install to/usr: because distributions don't support/usr/local properly. All kinsd of things won't work. Menu items, icons, dbus servers, you name it. More info here. - We don't overwrite glibc or gtk or any of your precious system components. Autopackages are desktop apps, remember? Worst that can happen is when your distribution's Gaim is overwritten. - As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed. - The average user wants desktop integration (menus, icons, etc.) to work. And right now, installing to/usr is the only way to do that.
In other words: you *can* set it to/usr/local by default, but then we can't guarantee that things like menu items will work correctly simply because all (yes, you read it: all of them; unfortunately there isn't a single distribution that gets/usr/local right) distributions have incomplete support for/usr/local.
(Un?)fortunately, distributions even support menu items/icons/etc in $HOME better than/usr/local!
"Great to know. (What happens if it installs a version of a library that is ABI incompatible with a version that the distribution ships?)"
It won't. - Dependencies are only installed if they're not already on the system. - If a package overwrites a system library, then the package is broken and must be fixed. Shipped dependencies are to be installed to private folders, as recommended by our guidelines, exactly to prevent DLL hells like that.
"Surprisingly, people in autopackage's target demographic probably would complain about autoconf..."
Yes they would. But my point was to explain how autopackage detects dependencies.
"But regardless, the question was how will autopackage deal with an ABI conflict (lets say the gcc-3.3->gcc-3.4 one) between itself and a library it wants to dynamically link with at runtime."
You are talking about the C++ ABI problem. We have done extensive research on that area, and we have a solution planned for autopackage 1.2 (due very soon now).
"What you focus on isn't the point; the issue was that dealing with the above will (most likely) require you to deal with a whole host of things which are decidedly not "desktop applications.""
We know that. And that's why we have done, and are still doing, extensive research about binary compatibility problems. We aren't selling hot air. We have put real efford into solving practical, real-world problems related to this.
Believe me, we have tried. Unfortunately the discussion often boils down to: - We (= the distro guys) don't like proprietary software so its not our problem. - We don't care about inter-distro compatibility. Not our problem. - RPM/DEB rules all. Everything else is evil. Really, we tried to negotiate. So far all attempts failed.
They don't like us because they want to centralize software packaging. Don't just blindly assume we're evil just because they're critical to us. Read what they write. For example:
"To even unpack the package, you must run arbitrary code supplied by an untrusted source." Untrusted source? Is the upstream developer an untrusted source? If he cannot be trusted, then why would one trust third party Gentoo packages?
"They install directly to the live filesystem." We have this little feature called "installing to $HOME". It won't touch/usr if you don't want it to. How hard is that?
"They do not support configuration protection." We backup stuff if they're being overwritten.
"They can clobber arbitrary files on uninstall." No proof. Bug reports please, because we sure haven't received any from our users.
"The entire format is completely unportable and highly tied to x86 Linux systems." The reason why that is so is because none of the developers have anything but x86 systems. It's a bit hard to support PPC if we don't have such a machine, right? We already have some stuff in place to make sure x86 packages aren't executed on other architectures. But that aside: let us go back to the original problem: software installation isn't easy enough for the average user. And what architecture does 99% the average user use? x86! Now there's the main reason why we focus on x86: because that's where our target group are! The software installation problem is pretty much unique to x86 Linux. Non-x86 architectures are usually servers, not desktops. They don't need autopackage, so why should we worry about them? PPC users most likely use MacOS instead of Linux, so there's not much point in supporting that either.
As for joey's blog: the only thing he's complaining about is that at the moment you cannot programmatically extract files from a.package. Average users don't even care about that! They just want the damn software to be installed and to work!
Yeah I haven't replied to everything but you get the point.
The plugins should be upgradable too. But what prevents you from doing that?
The problem is that, unless you make a distinction between system and desktop, the user will be presented with a huge list with thousands of packages. If my dad wants to upgrade mune he really isn't interested in seeing glibc and qt in that list. It's more a user interface problem.
"I sure hope that's a typo for/usr/sbin... If not, well, that's so horribly broken that I don't even want to get strarted with it. FHS anyone?"
It's either a typo, or the writer of the article wrote the wrong thing.
If you install an autopackage as root, it'll be installed to/usr. This can be customized by editing a configuration option. If you install an autopackage as user, it'll be installed to ~/.local.
"Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time."
What do you mean? Autopackage, too, keeps a database of installed files. You can remove a package by typing 'package remove foo' or using the graphical user interface.
"Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead?"
I don't really understand what you mean. But we detect dependencies in the same way like autoconf does: by directly scanning for their presence. But nobody seems to complain about that.
"Oh wait, autopackage is for "desktop packages only"."
You are correct. Is there something wrong with focusing on desktop applications? That is what average users care about.
As for Remnant's blog: we've replied to that before. And he may be the dpkg maintainer, but that doesn't mean he knows autopackage better than we do, or even understand why we designed it like this in the first place.
To me, Thunderbird's search features aren't good enough. I have thousands of emails, stored in different folders for organizational purposes. But I can't search for something in all folders like I can in GMail. I have to re-enter the search term for every folder. That really sucks. Plus, Thunderbird allows me to search for "Subject & Sender" or "Message body", but not both of them at the same time. At sucks a lot.
I have never needed CMYK or 16-bit support for my home photos. Most people are not pro photographers or even hobbyist phographers. The professionals will never touch Gimp even if it does support 16-bit and CMYK.
Slashdot Mirror
We don't; we do a reverse lookup. Upon installing a file, we check whether that file is already owned by a native package.
Did you miss the bit in which I said "As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed." ?
But let us go back to the problem. The user has two choices:
1. Install an autopackage of FooBar 2005 (latest version), which overwrites the existing copy.
-OR-
2. Not being able to install at all, and having to wait 3 months for a native package to appear.
Which one do you think is the better choice for the average user?
And again, "As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed."
You are correct. But the problem is, distributions refuse to fix
The fire marshal is specialized in extinguishing fires. They are not specialized in other areas. Likewise, the distro guys are specialized in packaging their *own* distros, but not inter-distribution packaging. You still shouldn't let them do the thinking for you.
Autopackage is used by high-profile projects like AbiWord, Inkscape and Gaim. Upstream trusts us. What do you think that means?
Does RPM/DEB provide that seperation? Last time I checked (today), RPMs *must* be installed as root. As the preinstall and postinstall RPM scripts can do whatever they want, including rm -rf
Autopackage is *open source*. If you don't trust us, you can inspect the source code. It's there, readable with vi, emacs, less or whatever your favorite text viewer is. You can easily search the header and scripts for trojans. Scripts aren't dangerous by themselves. Scripts are dangerous if they contain dangerous code. So if there is no dangerous code then what's the problem?
We're being used by high-profile projects like Gaim, AbiWord and Inkscape. Upstream trusts us. That should say something, right?
"end result is the support for when stuff breaks falls on the distros head."
No. People are supposed to report bugs to us or to the upstream developers.
"What the user wants is something the distro tries to address- just because autopackage comes along and states their desktop orientated, in no way makes them better, nor worse then the distro's focus of full integration and packaging of software."
You are correct. But the fact is, distros can't package everything. If you look at Linux forums you'll see that people often complains about:
- My package is not in the repository.
- My package is in the repository but isn't the latest version.
- The package in the repository is broken. (*cough* Fedora Extras galeon 1.3 *cough*)
And this is where autopackage jumps in. They provide an extra choice for people who aren't satisfied with the native package management system.
The reason why we allow root installs is because there are people who want to install software system-wide. And some things just work better when you install to /usr as root (unfortunately not all desktop environments fully support locating resources in $HOME). And this is also why we *ask* the user whether he wants to enter the root password.
/.local without asking."
All the complaints seem to come from power users who don't like the idea of a new packaging format. The inexperienced Linux users seem to love us, as can be seen from the feedback we get from them.
"Also, maybe autopackage has been updated since I last used it, but I was only prompted once for a root password. Subsequent package installations went straight to
Sounds like a bug. Are you using Ubuntu? It might be related to sudo.
"If you're really not interested in actually solving a problem, just say so."
I don't say so, which means I AM interested in solving the problem.
"Existing packaging systems Just Work for Linux PPC. Yours doesn't. How is that possibly an improvement?"
Autopackage's goal is not to be "better" than RPM/DEB. Autopackage's goal is not to surpass current packaging systems in every way possible. Autopackage is not supposed to completely replace RPM/DEB.
Let us go back to defining the problem. The problem is: software installation on Linux is too hard for the average user. And what do those users use? x86 Linux! Really, look at the numbers. Browse some Linux forums, mailing lists, newsgroups, etc. Almost every time people complain about software installation on Linux, it's about x86 Linux. Have you ever heard of people complaining about software installation on PPC Linux? I don't. The people who want a friendly OS on PPC all use MacOS X. Have you ever seen people trying to convert Mac users to Linux? I don't. Have you ever seen people trying to convert Windows users to Linux? I have, many times!
In other words: the problem just doesn't exist (or is too small) on Linux PPC, or people would complain about it. The software installation problem is pretty much unique to x86 Linux, as that's where the majority of the users are! And there's the real reason. 99.9% of the problem is on x86 Linux, so logically it only makes sense to focus on x86 Linux.
"I really don't see why this isn't the default way to do autopackage."
I don't know what you mean, as every time you install an autopackage, it asks you to enter the root password. If you want it to install to ~/.local, then just click "No Password" in that dialog. What is the problem?
"That seems like a rather large bit of hubris considering binary distros were already dealing with binary compatibility issues, long before autopackage existed."
I mean inter-distribution binary compatibility issues. Do distributions deal with that? So far I haven't seen any distribution who cares about being able to run their binaries on other distributions, or vice-versa. If you know one please let me know and I'll applaud them.
You are correct. We don't claim to solve *all* problems, but we do solve a great portion of them. We have received a lot of positive user feedback.
Then that library is utterly broken and must be fixed. We actively encourage developers to adhere to libtool version.
"This "solution" is to double or trebble the size of the packages distributed by compiling them for every possible ABI incompatible version."
Right now, there are only two major ABIs: the GCC 3.2 and the GCC 3.4 ABI. Nobody (at least, nobody who cares about the desktop) uses the pre-GCC 3.2 ABI these days.
And it won't double the size. We use binary diffs, and this saves a lot of space (roughly 70%-90%, depending on the binary). And a major part of desktop apps usually consists of data files; those are not duplicated. Autopackage 1.2 also features LZMA compression, which offers better compression than even bzip2 (which is used by RPM AFAIK; not sure about DEB).
Do you know a better solution though? At least this one works. Making it work is more important than making it perfect.
Frankly, to truly solve the problems, the Linux community has to start caring more about binary compatibility. But from what I understand, you seem to have already given up on that, by claiming that it's not possible to create portable binaries. But we have to start *somewhere*, don't we? The solutions may not be optimal, but at least they work.
The reason we don't deal with tarballs is because:
1. No desktop integration. Tarballs don't install menu items and icons for you to the right place. We do. We go into great length to deal with the myrads of different menu systems.
2. Binary compatibility. Tarballs are just that - tarballs. Part of the autopackage is research about binary compatibility. We figure out why binaries don't work on other distros, and try to fix that. Without a solution to binary compatibility problems, using any format is meaningless.
"And how about that button in the Window manager? Doubt Autopackage can handle that detail, as I use fvwm2."
You are correct, we don't support fvwm. But honestly: how many people use fvwm? More importantly: how many average users use fvwm? A simple cost/gain calculation reveals that we should focus on GNOME/KDE support instead. We intend to solve real-world problems with software installation on the desktop. We aren't trying to support every window manager out there, we aren't trying to replace RPM/DEB, we are trying to solve user-visible real-world desktop software installation problems.
In this case, yes. But usually this doesn't happen. Remember that autopackage targets desktop applications: i.e. the stuff that average users cares about, not server applications. I don't know many desktop applications that use epoll or other OS-specific APIs - they usually use portable APIs like the GNOME/KDE stack.
But, even if you must use epoll, there's still a way to solve that. As autopackage installation scripts are script-based, you can just do this:
1. Compile two binaries: one with epoll support, and one without (falls back to regular poll).
2. Put both of them in your autopackage.
3. Autodetect at runtime whether glibc and the kernel supports epoll.
4. Install correct binary.
It's more work, but it's possible. And it sure makes things a lot easier for the average user. In fact we use a similar method to solve the C++ ABI breakage problem.
This situation is currently impossible, as the native package manager will think that X isn't even installed, simply because it isn't in its database. For example, if you install gtk from source, then install the Gaim RPM/DEB, then RPM/DEB will complain that gtk is not installed even though it is.
Not so with autopackage. You can run autopackages as user and install to ~/.local. You don't have to give it root access if you don't want to. And as autopackage is open source, you can check the source code for trojans. Autopackages are tarballs with a shell script header. Anyone can check the shell scripts for trojans.
I'm not familiar with Conary, but do they take care of desktop integration stuff like menu items and icons? What about things like updating the icon cache? (If you don't do that some icons won't appear in the GNOME menu) Or the MIME cache?
And does Conary research inter-distribution binary compatibility? As far as I know we are the only group that have good knowledge about binary compatibility problems and actively try to solve them. Without a solution for binary compatibility problems, you cannot make inter-distribution packages no matter what packaging system you use.
No. It will only do that if you want it to do that. Install to $HOME if you're paranoid, or tweak the settings to not default to
- There's a good reason why we install to
- We don't overwrite glibc or gtk or any of your precious system components. Autopackages are desktop apps, remember? Worst that can happen is when your distribution's Gaim is overwritten.
- As of autopackage 1.2, autopackage even refuse to install if there's already a native version installed.
- The average user wants desktop integration (menus, icons, etc.) to work. And right now, installing to
In other words: you *can* set it to
(Un?)fortunately, distributions even support menu items/icons/etc in $HOME better than
It won't.
- Dependencies are only installed if they're not already on the system.
- If a package overwrites a system library, then the package is broken and must be fixed. Shipped dependencies are to be installed to private folders, as recommended by our guidelines, exactly to prevent DLL hells like that.
Yes they would. But my point was to explain how autopackage detects dependencies.
You are talking about the C++ ABI problem. We have done extensive research on that area, and we have a solution planned for autopackage 1.2 (due very soon now).
We know that. And that's why we have done, and are still doing, extensive research about binary compatibility problems. We aren't selling hot air. We have put real efford into solving practical, real-world problems related to this.
Believe me, we have tried. Unfortunately the discussion often boils down to:
- We (= the distro guys) don't like proprietary software so its not our problem.
- We don't care about inter-distro compatibility. Not our problem.
- RPM/DEB rules all. Everything else is evil.
Really, we tried to negotiate. So far all attempts failed.
They don't like us because they want to centralize software packaging. Don't just blindly assume we're evil just because they're critical to us. Read what they write. For example:
/usr if you don't want it to. How hard is that?
.package. Average users don't even care about that! They just want the damn software to be installed and to work!
"To even unpack the package, you must run arbitrary code supplied by an untrusted source."
Untrusted source? Is the upstream developer an untrusted source? If he cannot be trusted, then why would one trust third party Gentoo packages?
"They install directly to the live filesystem."
We have this little feature called "installing to $HOME". It won't touch
"They do not support configuration protection."
We backup stuff if they're being overwritten.
"They can clobber arbitrary files on uninstall."
No proof. Bug reports please, because we sure haven't received any from our users.
"The entire format is completely unportable and highly tied to x86 Linux systems."
The reason why that is so is because none of the developers have anything but x86 systems. It's a bit hard to support PPC if we don't have such a machine, right? We already have some stuff in place to make sure x86 packages aren't executed on other architectures.
But that aside: let us go back to the original problem: software installation isn't easy enough for the average user. And what architecture does 99% the average user use? x86! Now there's the main reason why we focus on x86: because that's where our target group are! The software installation problem is pretty much unique to x86 Linux.
Non-x86 architectures are usually servers, not desktops. They don't need autopackage, so why should we worry about them? PPC users most likely use MacOS instead of Linux, so there's not much point in supporting that either.
As for joey's blog: the only thing he's complaining about is that at the moment you cannot programmatically extract files from a
Yeah I haven't replied to everything but you get the point.
Come on. Autopackage has got as much to do with automake as Bill Clinton with Bill Gates.
The plugins should be upgradable too. But what prevents you from doing that?
The problem is that, unless you make a distinction between system and desktop, the user will be presented with a huge list with thousands of packages. If my dad wants to upgrade mune he really isn't interested in seeing glibc and qt in that list. It's more a user interface problem.
"I sure hope that's a typo for /usr/sbin... If not, well, that's so horribly broken that I don't even want to get strarted with it. FHS anyone?"
/usr. This can be customized by editing a configuration option. If you install an autopackage as user, it'll be installed to ~/.local.
It's either a typo, or the writer of the article wrote the wrong thing.
If you install an autopackage as root, it'll be installed to
"Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time."
What do you mean? Autopackage, too, keeps a database of installed files. You can remove a package by typing 'package remove foo' or using the graphical user interface.
"Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead?"
I don't really understand what you mean. But we detect dependencies in the same way like autoconf does: by directly scanning for their presence. But nobody seems to complain about that.
"Oh wait, autopackage is for "desktop packages only"."
You are correct. Is there something wrong with focusing on desktop applications? That is what average users care about.
As for Remnant's blog: we've replied to that before. And he may be the dpkg maintainer, but that doesn't mean he knows autopackage better than we do, or even understand why we designed it like this in the first place.
Aah, the find dialog. I never looked there, I always use the quickfind box. Why can't they make the quickfind box find more results?
To me, Thunderbird's search features aren't good enough. I have thousands of emails, stored in different folders for organizational purposes. But I can't search for something in all folders like I can in GMail. I have to re-enter the search term for every folder. That really sucks. Plus, Thunderbird allows me to search for "Subject & Sender" or "Message body", but not both of them at the same time. At sucks a lot.
"It can't be done with dynamic linking, despite what the Autopackage people tell you"
Dude, *we* aren't the only ones that tell you it can be done. The *users* also tell you it can be done. What more proof do you need?
"There's too much variety between distributions with things like libc and libstdc++ versions."
That is exactly why we have developed APBuild. We've done extensive research into finding out *why* glibc versions cause problems.
They HAVE to be expensive or bosses won't take them seriously. In the eyes of non-technical managers, expensive = good.
I have never needed CMYK or 16-bit support for my home photos. Most people are not pro photographers or even hobbyist phographers. The professionals will never touch Gimp even if it does support 16-bit and CMYK.
Last time I checked 16-bit channels != CMYK ?