ThirdPartyPackages

Revision 11 as of 2005-11-02 21:49:51

Clear message

Summary

Some software cannot be incorporated into Ubuntu's comprehensive package repositories. We should explore options for providing Ubuntu users with convenient access to such software.

Rationale

As Ubuntu gets bigger more and more commercial vendors are interested in providing their software for ubuntu. We need a convenient way to install this software. Currently installing software that is not inside our archives is harder than it needs to be.

Use cases

  • Alice wants to install a commercial image manipluation application. She installs it from the "commercial" component and gets a activation key directly from the vendor.
  • Bob is interested in a demo of a big database application. This feature limited application is availabe in the commercial section. After trying it out, he decides to purchase it and downloads a key file from the vendor.

Scope

This spec covers ubuntu.

Design

adding support for channels file

We can have a "proprietary-channels" package. The channel package contains a set of sources.list.d fragments that point to the vendors repositories that can easily be turned on. The fragments also contain additional meta-information like icons and desktop.files for gnome-app-install. The channel package are published in ubuntu-updates. The sources.list.d fragments points to repository setup by the vendor.

The vendors will have to send us updated channel information (if required).

Meta-information in the desktop file for commercial stuff

Additonal information for the g-a-i:

  • what channel the application is in

Additional information to display to the end user

  • Charge: free-beer, trial, pay
  • More-Information-URL: the url that points to the license
  • Redistribution: yes, no, limited === Content of the channel file === The channel package contains:
    • sources.list.d fragment that points to the archive of the vendor
    • some information about the channel and possibly a icon
    • key for the archive of the vendor
    • desktop files for gnome-app-install and icons for it

Gnome-app-installer

We will create a new component, called (to be confirmed) "proprietary". This is where we will store debs for software that is supported by somebody, but is non-free and possibly non-redistributable.

Gnome-app-install should be extended so that it contains information about these commercial applications as well. We will add these two checkboxes to the front page of the "Add Applications" tool (gnome app installer): 

    [x] Commercial software
    [ ] Unsupported software

This will turn on the universe / multiverse / commercial components in the following fashion:

Unsupported OFF

Unsupported ON

Commercial ON

commercial

commercial, multiverse, universe

Commercial OFF

(main, restricted only)

universe, multiverse

The commercial application should be turned off by default.

After turning on, AND installing the propriatary-channels package (this happens automatically), the user will see them in synaptic and gnome-app-installer. After the checkboxes are clicked, the user will be asked if he wants to update the package list.

The commercial applications will contain a additional Field "X-Gai-Commercial" (name not final yet) in the pseudo-desktop file that is used to identify commercial software and that contains license information and a URL to the license. For software that requires a key to activate and that is not usable without that key, a big warning needs to be displayed. This will ensure that the user does not download photoshop, only to discover that he won't be able to run it without paying for an expensive key.

installing debs directly

We also provide a convenient way to install deb files directly in a safe way. The user should be able to see what the debs contains (description, files) and the dependencies need to be analyzed and we have to check if they can be installed.

Open issues

Dealing with redistributability

  • some commercial software is dowloadable and redistributable
  • some cannot be redistributed
    • XXX see Kinnison re pools and components and put them into a non mirrored pool maybe?
    • XXX can we put full URL's in the Packages file? see Elmo?

Methods of activation of the software

  • Shareware (no activation, voluntary contribution)
  • Activation post install:
    • User goes to ISV web site, gets key, activates in product
    • FUTURE: Key management is done directly by gnome-app-install
    • FUTURE: Ability to add "lockable" repos, where the whole repo
      • is enabled after some transaction

We shouldn't support handing out license keys and supporting paying initially but this is a future goal.

misc

  • can these packages be published to a different pool, to prevent accidental mirroring?
  • What will be the interface for server-oriented apps, like Oracle and DB2?

    • -> provides a "pseudo" desktop file for that applications

  • do we want to manage a repository containing 3rd party s/w ? or just point to the repository supported by the 3rd party ?

    • -> we should support both. our solution supports both

  • should there be a commercial-security pocket? how does e.g. oracle handles security update right now? or service packs? how do the vendors support their updates ( security etc. )

    • -> we can't do better than the vendors here, if they don't support it, we

      • can't.

Adding software to the repo

  • the commercial component needs to be able to be updated post-release
    • once software is certified for that release (so the desktop files that describe the available stuff in gnome-app-install need to be updated in some way)

Implementation

GUI

The option to turn on the proprietary channel/repository should be easily discoverable. Options include - add a button at the bottom of the Add Application window which directly turns on the channel - add a button at the bottom of the Add application window called Preferences or Channels, which then opens the current Repository window. On that window there would be a button/box to turn on the proprietary channel

Install debs directly

To install debs in a save way there are two options. One is to add support for it to libapt itself. There is a baz branch for this in "apt--local-install--0". The current patch is rather intrusive and the apt maintainer does not particularly like it. The other alternative is to provide a application (that can be part of the apt package) that will analyze the deb and it's dependencies. If they can be satisfied it will be installed, otherwise it won't.

Code

Install debs directly

Some prototype work is being done to install deb files directly in the bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main

There are also test-packages available at: 

deb http://people.ubuntu.com/~mvo/gdebi/ /

Data preservation and migration

Outstanding issues

What is a good list of applications to have here?

we could look at this list for more ideas: http://www.ubuntuforums.org/showthread.php?t=80295

BoF agenda and discussion