ThirdPartyPackages

Differences between revisions 11 and 12
⇤ ← Revision 11 as of 2005-11-02 21:49:51 →
Size: 7993
Editor: 209
Comment: result after third bof
← Revision 12 as of 2005-11-03 00:01:41 → ⇥
Size: 7908
Editor: 209
Comment: cleanups
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
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.		 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.

It is possible to provide various levels of support to the vendors. In the simple case we help the vendor to make it easy for our users to discover there software and install it. This can be done via gnome-app-install and by providing support to install debs that are designed for ubuntu. At some point in the future it may involve supporting some infrastructure to pay for software and issue license keys.
Line 22: Line 24:
 * 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.		  * Alice wants to install a commercial image manipluation application. She installs it from the "commercial" component in gnome-app-install and gets a activation key directly from the vendor.
 * Bob wants to install skype. It is provided as a deb downloadable from the vendors site. He downloads it via mozilla and gets a dialog that tells him about missing dependencies and whether he wants to install software of the internet. He installs it and gets a working skype this way.
Line 27: Line 29:
This spec covers ubuntu. This spec covers ubuntu, the frontend initially covers gnome.
Line 31: Line 33:
=== adding support for channels file === There are two different use-cases that we want to support. The first is to provide commercial software with gnome-app-install that can come from external vendors. The second is to support direct installs of debs.
Line 33: Line 35:
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.		 === Extending gnome-app-install ===
Line 40: Line 37:
The vendors will have to send us updated channel information (if required). Gnome-app-install already contains desktop files for the available applications in universe and multiverse. Those desktop files contains the keys:
{{{
X-AppInstall-Package=synaptic
X-AppInstall-Section=main
}}}
Line 42: Line 43:
=== Meta-information in the desktop file for commercial stuff === This mechanism will be extended for proprietary applications to include additional keys. The key here is the concept of `channels`. A channel is a way for the vendor to provide software. Technically it is a sources.list fragment with additional meta-information that will be added to /etc/apt/sources.list.d/ (support for apt for this needs to be written/merged). The meta-information includes a icon for the channel and desktop-files/icons for gnome-app-install. We can use this pseudo desktop files for things like server applications as well.
Line 44: Line 45:
Additonal information for the g-a-i:
 * what channel the application is in		 The channels will be provided with a "proprietary-channels" package. Updated versions of that can be put into "dapper-updates" if new vendors join in. The sources.list.d fragments points to a repository setup by either the vendor or by us (if the vendor pays for that).
Line 47: Line 47:
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		 The vendors will have to send us updated channel information if e.g. if they put more user-visible packages into their repository or if there url changes. The "proprietary-channels package is updated then.
Line 52: Line 49:
 === Content of the channel file ===
 
 The channel package contains:		 The following information for proprietary applications is required:
 * Proprietary: yes/no
 * what channel the application is in (for g-a-i)
 * Charge: free-beer, trial, pay (to display to the user)
 * More-Information-URL: the url that points to the license/prices
 * Redistribution: yes, no, limited

The following information is put into the channel package for each vendor:
Line 60: Line 62:


=== 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):		 We will add these two checkboxes to the front page of the "Add
Applications" tool (gnome app installer):
Line 85: Line 78:
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.		 After turning on `proprietary` gnome-app-install will install the `proprietary-channels` package and read the additional information in it. The user can then search (or browse) the commercial offerings. If he decides to install one of them he will be subscriped to the vendors channel (his sources.list.d/ will be updated) and the package he selected will be installed. From this point on the vendors packages are in the normal "apt" space and available with apt/synaptic/aptitude. For packages that require the user to pay (and that are not usable without) a warning is displayed. This will ensure that the user does not download a big application, only to discover that he won't be able to run it without paying for an expensive key.
Line 90: Line 80:
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.		 In order to support hosting of propriatary software on our servers we will need to 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. It must go into a seperate pool to make sure that it's not mirrored.

It's the vendors responsibility to support security updates in it's channel. We can't do better than the vendors here and we rely on them.
Line 103: Line 89:
installed. installed. 
Line 105: Line 91:
== Open issues == == Future ==
Line 107: Line 93:
=== 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)		 In the future we may support keymanagment/payment ourself. This should probably integrated into launchpad. We may also support repositories that are "lockable" and that are only unlocked after some transaction.
Line 142: Line 97:
==== GUI ==== === GUI ===
Line 144: Line 99:
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		 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
Line 156: Line 111:
=== Install debs directly === ==== Install debs directly ====
Line 165: Line 120:
=== Data preservation and migration ===
Line 188: Line 142:

== BoF agenda and discussion ==

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.

It is possible to provide various levels of support to the vendors. In the simple case we help the vendor to make it easy for our users to discover there software and install it. This can be done via gnome-app-install and by providing support to install debs that are designed for ubuntu. At some point in the future it may involve supporting some infrastructure to pay for software and issue license keys.

Use cases

  • Alice wants to install a commercial image manipluation application. She installs it from the "commercial" component in gnome-app-install and gets a activation key directly from the vendor.
  • Bob wants to install skype. It is provided as a deb downloadable from the vendors site. He downloads it via mozilla and gets a dialog that tells him about missing dependencies and whether he wants to install software of the internet. He installs it and gets a working skype this way.

Scope

This spec covers ubuntu, the frontend initially covers gnome.

Design

There are two different use-cases that we want to support. The first is to provide commercial software with gnome-app-install that can come from external vendors. The second is to support direct installs of debs.

Extending gnome-app-install

Gnome-app-install already contains desktop files for the available applications in universe and multiverse. Those desktop files contains the keys: 

X-AppInstall-Package=synaptic
X-AppInstall-Section=main

This mechanism will be extended for proprietary applications to include additional keys. The key here is the concept of channels. A channel is a way for the vendor to provide software. Technically it is a sources.list fragment with additional meta-information that will be added to /etc/apt/sources.list.d/ (support for apt for this needs to be written/merged). The meta-information includes a icon for the channel and desktop-files/icons for gnome-app-install. We can use this pseudo desktop files for things like server applications as well.

The channels will be provided with a "proprietary-channels" package. Updated versions of that can be put into "dapper-updates" if new vendors join in. The sources.list.d fragments points to a repository setup by either the vendor or by us (if the vendor pays for that).

The vendors will have to send us updated channel information if e.g. if they put more user-visible packages into their repository or if there url changes. The "proprietary-channels package is updated then.

The following information for proprietary applications is required:

  • Proprietary: yes/no
  • what channel the application is in (for g-a-i)
  • Charge: free-beer, trial, pay (to display to the user)
  • More-Information-URL: the url that points to the license/prices
  • Redistribution: yes, no, limited

The following information is put into the channel package for each vendor:

  • 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

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 proprietary gnome-app-install will install the proprietary-channels package and read the additional information in it. The user can then search (or browse) the commercial offerings. If he decides to install one of them he will be subscriped to the vendors channel (his sources.list.d/ will be updated) and the package he selected will be installed. From this point on the vendors packages are in the normal "apt" space and available with apt/synaptic/aptitude. For packages that require the user to pay (and that are not usable without) a warning is displayed. This will ensure that the user does not download a big application, only to discover that he won't be able to run it without paying for an expensive key.

In order to support hosting of propriatary software on our servers we will need to 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. It must go into a seperate pool to make sure that it's not mirrored.

It's the vendors responsibility to support security updates in it's channel. We can't do better than the vendors here and we rely on them.

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.

Future

In the future we may support keymanagment/payment ourself. This should probably integrated into launchpad. We may also support repositories that are "lockable" and that are only unlocked after some transaction.

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

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

ThirdPartyPackages (last edited 2008-08-06 16:28:30 by localhost)