ARB /opt requirement

Contents

  1. ARB /opt requirement
    1. Current situation
    2. Analysis
      1. extras.ubuntu.com
      2. dev release + backports
      3. In favor of /opt
      4. In favor of extras archive
    3. Options
    4. Addressing the concerns separately
    5. User Stories
    6. More info
      1. Previous discussion
    7. Docs

This page discusses the current state of the /opt requirement for apps.

Current situation

Apps which go to the AppReviewBoard, currently have the requirement to install files into /opt. This was decided in order to avoid file system conflicts by installing into a different location. Also does it make it harder to ship broken plugins. The reasoning was also that the FHS says that /opt is for third-party vendors.

There are some exceptions, for example unity extensions and .desktop file are allowed to live elsewhere. These exceptions are approved by the TB.

The /opt install location has been reviewed several times with the TB, and each time the decision has been made to keep the requirement (see Previous discussion, below). The ARB recommends that effort this cycle be directed toward improving packaging tools to handle installation in /opt, and improving documentation for new developers who continue to submit apps installed in /usr. Canonical's Community Team would also like to raise (again) the possibility of removing the /opt installation requirement. Their perspective is that making ARB packaging more similar to the Ubuntu archives will simplify the process for app developers (no special documentation or tools, and no need to maintain special packaging for ARB apps), improve integration between ARB apps and the rest of Ubuntu, and so enhance the success of Ubuntu as an app platform.

The ARB spends a good deal of review time on educating submitters, fixing packaging, and sometimes even rejecting apps that likely would be approved through Debian/Ubuntu/backports (though, they also try to help those developers continue in the appropriate channel). The /opt install requirement does add to this work, but it's not clear whether the addition is substantial. The time required is certainly no more than the time spent adding the additional meta-data required by the Software Center for apps in extras (which is another unrelated ARB packaging requirement).

Analysis

extras.ubuntu.com

The current ARB process makes it very hard for submitters to it right on their own, the process is slow, the regular docs don't focus on it.

Relaxing the /opt requirement and looking for better ways to address the initial concerns would pave the way to make Ubuntu a successful app platform. ARB apps are the only place where we make these very involved requirements (PostReleaseApps/SecurityChecklist), we don't address file conflicts generally anywhere else.

That said, the process is in place, the submission procedure documented and a team dedicated to helping with. The process on the submission-side is light-weight (upload to PPA, state which release it should go in) and we'd want to keep it that way.

Having extras.u.c means that a separate archive has to be maintained and checked.

dev release + backports

Another alternative would be to get apps into the development release and backport them. This would have numerous advantages: the regular tools and docs would work fine and it would invite co-maintenance and patches for the app.

The disadvantages are quite clear also: It needs archive admin and backport team member intervention. To mitigate this somewhat, ARB members could join the Backports team.

There are open questions as well:

There have been plans to open backports for the next release at feature freeze, so quantal-backports would be able to accept new apps at the point where they're not accepted for universe any longer. https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-bof has some brief notes on this.

To emulate the currently implemented mechanism to expire apps (just keep them for one release, if the author does not request a reupload), we could do this manually (if we'd use backports) once a cycle.

In favor of /opt

In favor of extras archive

Options

  1. No change
  2. No change, but improve the tools to handle /opt
  3. No change, but add backports as an alternative path for apps submitted to ARB
  4. Relax /opt requirement, publishing through extras
  5. Relax /opt requirement, publishing through Ubuntu dev release and backports

Addressing the concerns separately

User Stories

More info

Previous discussion

Docs

OptRequirement (last edited 2012-04-30 20:54:43 by static-50-53-5-218)