http://brainstorm.ubuntu.com/item/21385/
[-57 votes] Solution #1: Create D-BUS API for installers


[259 votes] Solution #2: Create a universal package format


[129 votes] Solution #3: Support applications for single users


[-35 votes] Solution #4: Create libraries/shell script allowing to install package in specify directory


[41 votes] Solution #5: Autopackage, anyone?


[36 votes] Solution #6: apt capable of install and manage any software on earth


[10 votes] Solution #7: Sandbox for installers.


[-13 votes] Solution #8: New compatibility layer


[7 votes] Solution #9: make a gui for alien, and make it be default for rpm files


[19 votes] Solution #10: DEB packages are good!!! Promote them harder!!!


[0 votes] Solution #11: Create hybrid/common package format.


[0 votes] Solution #12: Add Autopackage support in Ubuntu Software Center


]]> en-us Thu, 10 Sep 2009 07:55:17 +0000 Wed, 30 Nov 2011 21:22:01 +0000 QAPoll module http://brainstorm.ubuntu.com/idea/21385/ Thu, 10 Sep 2009 07:57:14 +0000 Thu, 10 Sep 2009 07:59:52 +0000 Fri, 11 Sep 2009 02:07:01 +0000 Fri, 11 Sep 2009 03:06:36 +0000
@Solution #3: This is exactly what I think. I have describe in my solution multiple parts of system permission, like /opt for installing application by normal user, /sbin for installing system wide applications, etc. Additionally my idea include policy to overwrite files. How did you like do this by packaging system? Many programs have compiled-in libraries path or needs to set special environment variable. Package describes where we should put files included inside. We can use chroot, but we don't provide users pace chroot yet. Using chroot method will cause additionally problems.]]> Fri, 11 Sep 2009 06:02:07 +0000 Fri, 11 Sep 2009 06:04:32 +0000
All the developers need to do is create a user-level script that extracts the game data and adds a shortcut to the menu.

This is a not a linux problem, this is developers assuming that they know better than their customers and DEMAND that their installer script run as root even though the only reason for that is if you are installing for multiple users.]]> Fri, 11 Sep 2009 10:38:43 +0000
Installing an application for a single user should ONLY affect the user's home directory, not /opt or anything else outside the user's home directory. The only exception is that it's OK to use /tmp for temporary storage.

No new API is needed for this, only changes to dpkg/apt and perhaps a different packaging practice.

(Lachu is correct that we don't need to change behavior of system menus, they already work as desired.)
]]> Fri, 11 Sep 2009 10:55:43 +0000
The topic was not: installing software for user
but: installers sucks, because some needs root privileges to copy files into system directories.
Why we should giving them root privileges?]]> Fri, 11 Sep 2009 11:59:13 +0000
Without first solution satisfied, we don't make world better. Software companies will still making installers, but installers are bad think.]]> Sat, 12 Sep 2009 18:02:08 +0000
Imagine specialized interdistribution packaging system to install package into specify directories. Default option should be /usr/share/ for shared data(example application icons, new wallpaper) and /opt/app_folder for others(binaries, libraries, unshared data, like levels, sounds). This packaging system should prevent to setting suid or guid or setting specify owner of file or access rights.

It should use PackageKit to solving dependency in first step. If PackageKit fails, it can download package from own repository or from internet(specified source - if user agree). Next it will generate runner as described in #4 idea. Application provided by this package system should be linked with path resolver(as solution #4). Path resolver should have get_path_for_resource(char *res_name, int type, char *mime), where type can be BINARY, LIBRARY, SHARED_DATA, WALLPAPER, ICON, LINK, SOUND, VOICE, CURSOR, UNSUPPORTED_DATA.

What is most interesting in this idea is packaging system above other packaging system. PolicyKit can helps us, because it provides package naming scheme(so it no way to some package supported by packagekit have different name).]]> Sun, 13 Sep 2009 13:27:18 +0000 Tue, 15 Sep 2009 20:51:42 +0000 ]]> Wed, 16 Sep 2009 09:53:51 +0000
I must admit PackageKit force common naming scheme for packages. We can use this scheme in many places.

I must tell also, that Ubuntu don't contains PackageKit.]]> Thu, 17 Sep 2009 17:38:16 +0000 Sun, 20 Sep 2009 19:33:30 +0000
Idea to place files owned by root is no good and possibly you need, that other user can user installed application.]]> Sun, 20 Sep 2009 19:34:36 +0000 Tue, 29 Sep 2009 16:52:53 +0000
That's all. No magic. It will allow to working with many packaging system at the same time. And of course, there should been API for this - very similar to I suggest on first solution.]]> Fri, 02 Oct 2009 13:03:38 +0000 Fri, 02 Oct 2009 13:05:59 +0000
I'm the current main developer of Autopackage and have to agree with solution #5. Why start from scratch?
Autopackage already supports solution #3.]]> Wed, 07 Oct 2009 09:13:09 +0000
As far as dependencies being an issue, it doesn't require the "main" solution the LSB is implementing which is to make all distros have a standard set of libraries. While that may be somewhat helpful, all that is needed is a system to get users the required packages when they want something, and for that you just need a proper standardized way of communicating. Otherwise, if you include all libraries with your package then that gets rid of that, but it would be nice if there was something in place so you didn't have to waste that bandwidth.

Linux should utilize standards to wazoo and back, have them be available to make things more interoperable, so this is something which definitely needs attention.

Software on Linux is lacking enough as it is. Don't make things worse by fragmenting the Linux software ecosystem. Love your developers and give them the ability to release a single package for users to download. (and on a related topic, make adding repositories to install and then keep the software up-to-date easy, too)]]> Wed, 07 Oct 2009 11:49:09 +0000 Wed, 07 Oct 2009 14:39:00 +0000 Thu, 08 Oct 2009 00:56:14 +0000 Sat, 10 Oct 2009 12:15:44 +0000 Wed, 28 Oct 2009 07:47:15 +0000 Wed, 30 Nov 2011 21:22:01 +0000