AutopackageIntegration

Summary

Autopackage Integration - Autopackage integration in Ubuntu to make it easy for commercial software to have installers (also have a look at 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'

Answer to HiddeBurgmans: I specially find dangerous that "polluted" here can mean "polluted by viruses". A autopackage may delete all your home files or steal personal information. Windows has shown us that no warning dialog will stop users from installing such packages, no matter how much usability or informatin you throw at it. I think that users should be able to install packages from the internet - but those packages should NOT be able to access to your home account files. SELinux is the right answer here, IMO: Install whatever you want, EVEN viruses, but don't compromise your security in ANY way. At least that's how I think operative systems should send antivirus vendors to /dev/null Wink ;)

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 ...

Comment by Derick Eisenhardt

With Mark's recent post on what his goals and vision for Edgy Eft is, Autopackage will be needed more than ever now. If users wanting a "stable" version of Ubuntu, are to be told they need to stick with Dapper, even after Eft is full released, then users are going to need a way to obtain new versions of software. Sure, there's backports, but if we have 2 or 3 releases before another "Long Term" version of Ubuntu is released, I could see that getting really messy, very easily.

Autopackage does go against alot of people's preconcieved notions of what a distro's repository is for it seems, but in fact I believe it merely refines them. If we really want to give users Choice, then we need to give them the ability to easily install software from a 3rd party. Sure, give them warnings... tell them that Ubuntu holds no responcibility on it... but still make it easy for someone to go this route if they so choose.

The next version of AutoPackage after 1.2 will most likely focus on integrating with native package managers, so if some Ubuntu devs got on board, it will have an even better chance of working. As stated in prior comments, the idea is to have AutoPackage check to see if there's already a version available in the distro repository and then decide if it should install the .package or the distro specific package from the repos. This would be especially useful for dependencies.

With the new direction it seems Ubuntu is about to go in, this just seems to be the best option for LTR users, and even current release users at times.

BoF agenda and discussion

AutopackageIntegration (last edited 2008-08-06 16:16:25 by localhost)