AutopackageIntegration

Revision 7 as of 2005-10-29 19:44:58

Clear message

Summary

Autopackage Integration - Autopackage integration in Ubuntu to make it easy for commercial software to have installers (also have a look at [WWW] klik)

Rationale

Use cases

Scope

Design

Implementation

Code

Data preservation and migration

Outstanding issues

HiddeBrugmans - Do we really want any user to be able to install random packages from random internet sites? People will quite easily mess up their systems this way, and both autopackage and klik have drawbacks. It's not feasible to have *anything* on earth in universe, but we should take care not to turn ubuntu into a system that can easily be 'polluted'

Comment added by forbesguthrie

Unfortunately a lot of users will push for this integration. I think the best of both worlds can be achieved here. Have it integrated into synaptic so it tries to install it from the repositories first.

User Joe Bloggs want to install the latest PackageX. He sees a link on web page and downloads the PackageX AutoPackage. When he tries to run this on his gleeming new Dapper Smile :) Ubuntu box this is what might happen:

  • Synaptic kicks in and searches for the package (and same version) in Main, if found it installs it from there and lets the user know that it was installed from the repositories.
  • If it can't find it in Main, it searches other repositories for it (offering to add them if required).
  • If it can't find the same (or newer) version in a repository, then it offers an older version if available.

  • If the user declines to use an older version or a version cannot be found, then it will install using AutoPackage after displaying a dialog box explaining the dangers of installing packages from the internet (spyware, trojans, etc) and that if packaged badly could break other packages,etc.

  • In that case Synaptic would record the package name and version and regularly check the repositories for a match. If in the future it found a version on the repositories, then it would offer to replace the AutoPackage. The synaptic/repository server could also see which packages users were frequently installing through AutoPackage and better prioritise packaging for the repositories.

This way the users are happy and can install stuff from AutoPackage if they really want, but Ubuntu always tries to give them the best solution if its available. Just my $0.02

Comment added by TristanWibberley

I really don't think package installation that requires running things as root should ever be made easy unless the package is from Ubuntu. If users want to shoot themselves in the foot, let them go and find the gun store and buy the ammo. Don't put the gun in their hands and aim it for them. Autopackage requires running the third party's code as root since an autopackage package is a shell script.

If you are going to make it easy to install third party untrusted packages, let them be installed through dpkg without running any pre/post install/removal scripts. Perhaps, though, alien can be used to run the autopackage script in a safe environment and create a "dumb" deb. That might require wrappers for registration programs like gst-register that create safe scripts. They can then be forced into /opt preventing the typical user's PATH from running installed third party binaries by accident.

Comment added by Sean Middleditch

AutoPackage does not require running things as root. Users can install packages without root access using AutoPackage, so long as the software is relocatable. AutoPackage provides some advanced tools for easily making any software relocatable.

The idea that users are all too dumb to be trusted with AutoPackage is both egotistical and useless. As a very experienced user and developer of UNIX systems, I myself find AutoPackage incredibly convenient. Ubuntu will *NEVER* contain every software package, and quite simply real users have real needs that often require software Ubuntu doesn't provide.

There are also software packages such as games which just can't be included in Ubuntu. Good games are almost universally proprietary, and almost universally take up 400MB - 5GB all on their own. Indepedent of whether you think proprietary games are "wrong," real people want to play them, and a distribution-independent installer framework like AutoPackage is really necessary for them. Installing games is THE - I repeat, THE - biggest reason I can't get most people using Linux. It's actually easier to install a Windows game using WINE on Linux than it is to install a Linux-native game on Linux. That's just silly.

If users really want third-party software, they're going to get it, whether they do it using Synaptic, AutoPackage, or continuing to run their existing OS that doesn't intentionally try to stop them from installing the software they want. Ubuntu can either actually attempt to be useful and helpful and make it easy to install said software, or it can just be part of the problem and help ensure that users stick to an "easier to use" OS that doesn't stop them from doing what they want.

There is no compelling reason to keep AutoPackage out of Ubuntu other than unrealized fears of users shooting themselves in the foot, something they can just as easily do with Synaptic. (It's simple to add a new repository and install packages from any third-party site; and unlike AutoPackage, Synaptic actually *does* require everything to be done as root.)

Comment by HenrikOmma

Would it be possible to have a clean-room install for unofficial applications? These applications could be installed with their dependencies in such a way that it did not interfere with the rest of the stable system. The normal Ubuntu system would be seen as read only by this environment (except possibly /home). It would contain 'symlinks' to the standard system libraries but could also point these at custom versions which would be included in this clean-room environment. Once the application became available in Ubuntu proper in the version that the user wanted (if ever) this clean room could be removed and the official version could be used.

The concept is similar to the chroot environment used to build packages, but instead of seeing a standard 'bare' system the application would see the user's system in it's current state, plus possible local overrides. How much extra diskspace would be needed to have several such clean-rooms installed on the system would have to be investigated, but storage is cheap ...

BoF agenda and discussion