ThirdPartyPackages

Differences between revisions 10 and 12 (spanning 2 versions)
⇤ ← Revision 10 as of 2005-11-01 22:44:07 →
Size: 6614
Editor: 209
Comment: adding details about channels
← 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 6: Line 6:
 * '''Packages affected''':   * '''Packages affected''':
Line 9: Line 9:
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. 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.
Line 13: Line 15:
As Ubuntu gets bigger more and more commercial vendors are interessted in providing there 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 17: Line 24:
 * Alice wants to install a commercial image manipluation application. She install it from the "commercial" component and gets a activation key directly from the vendor.
 * Bob is interessted 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 22: Line 29:
This spec covers ubuntu. This spec covers ubuntu, the frontend initially covers gnome.
Line 26: 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 28: Line 35:
We can have a "proprietary-channels" package. The channel package contains a
sources.list.d fragments that points to the vendots repository that can easily
be turned on and 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 34: Line 37:
The vendors will have to send us updated channel information (if required).
    
=== Gnome-app-installer ===		 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 38: Line 43:
We will create a new component, called (to be confirmed) "propriatory". This is where we will store debs for software that is supported by somebody, but is non-free and possible non-redistributable. 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 40: Line 45:
Gnome-app-install is extended so that it contains information about this commercial applications as well. We will add these two checkboxes to the front page of the "Add Applications" tool (gnome app installer): 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):
Line 44: Line 67:
    [ ] Unsupported softwareThere will be a GUI option     [ ] Unsupported software
Line 51: Line 74:
|| Commercial OFF || (main, restricted only) || universe || || Commercial OFF || (main, restricted only) || universe, multiverse ||
Line 53: Line 76:
The commercial application should be turned off by default.  The commercial application should be turned off by default.
Line 55: Line 78:
After turning on, AND UPDATING packages files, will see them in
synaptic and gnome-app-installer. After the checkboxes are clicked, the user will get 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 58: Line 80:
The comcerial applications will contain a additional Field "x-gai-commcercial" (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 a big warning needs to be displayed to make sure that the user does not downloads photoshop to discover that he won't be able to run it. 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 62: Line 86:
We also provide a convenient way to install deb files directly in a save way. The user should be able to see what the debs contains (description, files) and the dependencies needs to be analyzed and it must be checked if they can be installed. 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.
Line 64: Line 91:
== Open issues == == Future ==
Line 66: 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"repo's, 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 ===
   * should there be a commercial-security pocket? how does e.g. oracle handles security update right now? or service packs?
   * 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?
   * do we want to manage a repository containing 3rd party s/w ? or just point to the
      repository supported by the 3rd party ?
   * how do the vendors support their updates ( security etc. )


=== 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 needs 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 103: Line 97:
==== GUI ==== === GUI ===
Line 105: 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 112: Line 106:
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.         		 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.
Line 119: Line 111:
=== Install debs directly === ==== Install debs directly ====
Line 121: Line 113:
Some prototype work is beeing done to install deb files directly in the bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main Some prototype work is being done to install deb files directly in the bzr archive at http://people.ubuntu.com/~mvo/bzr/gdebi--main
Line 128: Line 120:
=== Data preservation and migration ===
Line 132: Line 123:
== BoF agenda and discussion == What is a good list of applications to have here?

 * DVD playing software?
 * Skype
 * CrossOver Office
 * Opera
 * vmware
 * Arcad (http://www.arcad.de)
 * winex (cedega)
 * LGP games (http://www.linuxgamepublishing.com)
 * staroffice
 * neverwinter nights
 * acroread
 * Unreal
 * Doom3
 * limewire

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

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)