Written by Lachu the 10 Sep 09 at 07:55.

Ubuntu(and other distribution) should provide D-BUS based API for installer/uninstallers. You will get extra points if you integrate it with package database ;-) .

It should been integrated with PolicyKit, so administrators can give users access to install many kind of software(example software, which no needs setting suid bit and installing in /opt and don't change any files, can be installed by normal user; software which needs install in /sbin or /bin or /usr/bin, /usr/sbin should be installed only by superuser; or whatever).

This API should gives many functions, like copy executable into system directory(/bin), copy executable into superuser directory(/sbin, /usr/sbin or whatever), install user library(/usr/lib), install system-wide library(/lib), change file(delete existing file or writing own in the same place), change group of file, change owner of file, set uid bit, set guid bit, install nonexecutables(data) to /usr/share/*, installing user software(only have access to /opt), start installation.

All this action will be logged and reported. Additionally user may have simple uninstall software by system tools, because all performed operation are logged.

Installer should first call start installer function, so system show message to user like: This program will install software - continue? If user agree, DBUS returns the path, where the installer should unpack all of the files (in /tmp directory). Of course installer should register software name, etc., but it is long term task. If this is a game, it should install in /opt, so it call DBUS API to copy file from unpack folder into specify /opt folder, like copy_file_to_opt(file_name, opt_suffix).

Ubuntu(and other distribution) should provide D-BUS based API for installer/uninstallers. You will get extra points if you integrate it with package database ;-) . It should been integrated with PolicyKit, so administrators can give users access to install many kind of software(example software, which no needs setting suid bit and installing in /opt and don't change any files, can be installed by normal user; software which needs install in /sbin or /bin or /usr/bin, /usr/sbin should be installed only by superuser; or whatever). This API should gives many functions, like copy executable into system directory(/bin), copy executable into superuser directory(/sbin, /usr/sbin or whatever), install user library(/usr/lib), install system-wide library(/lib), change file(delete existing file or writing own in the same place), change group of file, change owner of file, set uid bit, set guid bit, install nonexecutables(data) to /usr/share/*, installing user software(only have access to /opt), start installation. All this action will be logged and reported. Additionally user may have simple uninstall software by system tools, because all performed operation are logged. Installer should first call start installer function, so system show message to user like: This program will install software - continue? If user agree, DBUS returns the path, where the installer should unpack all of the files (in /tmp directory). Of course installer should register software name, etc., but it is long term task. If this is a game, it should install in /opt, so it call DBUS API to copy file from unpack folder into specify /opt folder, like copy_file_to_opt(file_name, opt_suffix). I know is less secure than installing package, but is more secure than giving installer root privileges.

Written by dandart the 10 Sep 09 at 20:43.

Create a format that all distros can use and is easy to implement. Perhaps integrate into Apt/Rpm or have packages that both can understand somehow. Then we can download "Linux" package without having to worry if we want Apt or Rpm.

Create a format that all distros can use and is easy to implement. Perhaps integrate into Apt/Rpm or have packages that both can understand somehow. Then we can download "Linux" package without having to worry if we want Apt or Rpm.

Written by andruk the 11 Sep 09 at 02:12.

The reason apt needs root permissions is because the applications it installs are installed system-wide and therefore affect other users. If we allowed users to install programs to their home directory, then they could run their installed applications without affecting other users, and therefore wouldn't need to give apt root access.

This would have advantages with home users because my Applications menu wouldn't get cluttered when my daughter installs Barbietown to her home directory.

This would have advantages with sysadmins because they can run a piece of software from their home directory to test it out before installing it system-wide.

The system paths would have to be modified to look for libraries and executables in the home directory, but applications like Xournal already support this. This would also require the Applications menu to look in the user's home directory for the menus as well.

The reason apt needs root permissions is because the applications it installs are installed system-wide and therefore affect other users. If we allowed users to install programs to their home directory, then they could run their installed applications without affecting other users, and therefore wouldn't need to give apt root access. This would have advantages with home users because my Applications menu wouldn't get cluttered when my daughter installs Barbietown to her home directory. This would have advantages with sysadmins because they can run a piece of software from their home directory to test it out before installing it system-wide. The system paths would have to be modified to look for libraries and executables in the home directory, but applications like Xournal already support this. This would also require the Applications menu to look in the user's home directory for the menus as well.

Written by Lachu the 12 Sep 09 at 17:59.

Like in solution #3:
The main problem is many application have hardcoded path. There's no way to detect/guess path of specified file. Of course, we can recompile package, but it lack functionality for users.

The solution is simple. Create script scheme for setting environment, where specify files are placed. It should set PATH, LD_LIBRATY_PATH, XDG_HOME, CONFIG_PATH, etc. Script will also checking dependency and fixing it if not satisfied(also using install into directory technology).

Create also library, which allows program to read these setting/environment. Program should don't read file from /etc/program_config, but from $CONFIG_PATH/program_config.
If some environment isn't set, library should return default value.

User will have many scheme of installing application - install in: user home directory, system-wide(/), opt(/opt), custom paths.

And of course -- allow to set flag SUPPORT_PATH_SELECTING for package.

Like in solution #3: The main problem is many application have hardcoded path. There's no way to detect/guess path of specified file. Of course, we can recompile package, but it lack functionality for users. The solution is simple. Create script scheme for setting environment, where specify files are placed. It should set PATH, LD_LIBRATY_PATH, XDG_HOME, CONFIG_PATH, etc. Script will also checking dependency and fixing it if not satisfied(also using install into directory technology). Create also library, which allows program to read these setting/environment. Program should don't read file from /etc/program_config, but from $CONFIG_PATH/program_config. If some environment isn't set, library should return default value. User will have many scheme of installing application - install in: user home directory, system-wide(/), opt(/opt), custom paths. And of course -- allow to set flag SUPPORT_PATH_SELECTING for package.

Written by o-bin-lad3n the 15 Sep 09 at 20:05.

This is much like #2, but why start from scratch?
We could push for better support and integration of autopackage with apt, rpm, etc.
Also, I think the need for root-permissions itself is not the real problem, it's the need to blindly trust the file you just downloaded. Of course, there is always a way to mess with a system, when the user executes your software, but this would be way better than "sudo ./somefileijustdownloaded". Autopackage can run with user rights and install into your home directory. And you can still integrate gpg-keys with this solution.

I'm not suggesting this as THE universal package format, but as a common solution for third party/proprietary software and commercial games.

This is much like #2, but why start from scratch? We could push for better support and integration of autopackage with apt, rpm, etc. Also, I think the need for root-permissions itself is not the real problem, it's the need to blindly trust the file you just downloaded. Of course, there is always a way to mess with a system, when the user executes your software, but this would be way better than "sudo ./somefileijustdownloaded". Autopackage can run with user rights and install into your home directory. And you can still integrate gpg-keys with this solution. I'm not suggesting this as THE universal package format, but as a common solution for third party/proprietary software and commercial games.

Written by darkjavi the 21 Sep 09 at 16:47.

And what about giving to apt/aptitude/synaptic the ability to control/install any software on earth not only deb packages.
apt could run the instalation from is inside and chroot the destination of the files generated by the installer into his own folders, so we can manage all the computer software from a single interface

And what about giving to apt/aptitude/synaptic the ability to control/install any software on earth not only deb packages. apt could run the instalation from is inside and chroot the destination of the files generated by the installer into his own folders, so we can manage all the computer software from a single interface

Written by Lachu the 23 Sep 09 at 17:29.

Create sandbox for installers. It will check selinux context and when it isn't designed for installers, it will change it and fork with exec on executable file! It can't sets UID/GID bits or change any existing file, but can access to system directories.

Create sandbox for installers. It will check selinux context and when it isn't designed for installers, it will change it and fork with exec on executable file! It can't sets UID/GID bits or change any existing file, but can access to system directories.

Written by Afroman10496 the 27 Sep 09 at 02:31.

You all know how Wine works, right: importing an opensource clone of the Windows API. Now, imagine that for the Red Hat YUM/RPM compatibility. It's already opensourced, so you won't have to actually clone it. Also, you already have most of what you need because it's all Linux :>. Just offer it as a regular package and when users click on the .rpm just offer a dialog asking if they want to install it or Alien, showing all the pros and cons.

You all know how Wine works, right: importing an opensource clone of the Windows API. Now, imagine that for the Red Hat YUM/RPM compatibility. It's already opensourced, so you won't have to actually clone it. Also, you already have most of what you need because it's all Linux :>. Just offer it as a regular package and when users click on the .rpm just offer a dialog asking if they want to install it or Alien, showing all the pros and cons.

Written by ratdude747 the 27 Sep 09 at 22:01.

that would fix the rpm issue. beginners seem to get "scared" of the command line, and a gui saves time. that way, no matter whether they download an rpm or a deb, they are covered.

making it the default app for rpm would make it so a beginner wouldn't extract it by accident with archive manager. maybe you could then auto-load the resulting .deb.

that would fix the rpm issue. beginners seem to get "scared" of the command line, and a gui saves time. that way, no matter whether they download an rpm or a deb, they are covered. making it the default app for rpm would make it so a beginner wouldn't extract it by accident with archive manager. maybe you could then auto-load the resulting .deb.

Written by warlock24 the 7 Oct 09 at 17:38.

Do not multiply another installer formats, apis, ect. they only do unnecesary complicity of Ubuntu. Promote DEB packages to become unofficial standard for every linux. Develop visual tools for easy and fast creation of deb files (something like debGLADE?).

Do not multiply another installer formats, apis, ect. they only do unnecesary complicity of Ubuntu. Promote DEB packages to become unofficial standard for every linux. Develop visual tools for easy and fast creation of deb files (something like debGLADE?).

Written by Lachu the 28 Oct 09 at 07:42.

Not create new package format/packaging system, but allow to pack many packages into single archive. Structure will looks like this:

root
|
+definition&scripts
| |
| +deb
| +rpm
| .....
|
+files(must have structure like tar.gz - if in specify distribution one file must be moved into other directory, it's task for script)
|
+common definitions (name of author, license, features - installation into directory, etc.)


How distribution should handle it? In simple way. It will only unpack it into /tmp and handle as normal package(ex. run installation script for this distribution). It can also generate .deb or .rpm.

It should helps users, who like to download software from network. It can also helps game creators, because CD's can be used as repository of software.

Not create new package format/packaging system, but allow to pack many packages into single archive. Structure will looks like this: root | +definition&scripts | | | +deb | +rpm | ..... | +files(must have structure like tar.gz - if in specify distribution one file must be moved into other directory, it's task for script) | +common definitions (name of author, license, features - installation into directory, etc.) How distribution should handle it? In simple way. It will only unpack it into /tmp and handle as normal package(ex. run installation script for this distribution). It can also generate .deb or .rpm. It should helps users, who like to download software from network. It can also helps game creators, because CD's can be used as repository of software. Maybe there can occurs some problems with binaries, but most data of program is a resources, like icons, graphics, etc. Resources are shared, so there is a reason to create hybrid format.