OptRequirement

ARB /opt requirement

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:

  • what do we do about apps which work only in the stable release and not in the development release?
    • maybe do an upload just to -backports?

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

  • ARB apps are not in the PATH, and so are a lower security risk
  • ARB apps avoid file-path conflicts with packages in main, universe, etc
  • Simplified structure: App authors can think of their apps as a "bundle" that lives in /opt/extras.ubuntu.com/myappname.

In favor of extras archive

  • We are currently able to publish an app with a 1 day turn around (review, voting, publishing) if the app is well packaged and meets the requirements. Approval by the archive admins and then by backports will take longer, even under a best-case scenario. But, we want to be working on making that turn-around time even shorter than 1 day, a few hours at most.
  • We encourage all new packages to submit through Debian, not Ubuntu. We don't want to increase the number of apps only in Ubuntu. We don't want to increase the load on Ubuntu archive admins.

  • Backports only accepts submissions that are already in at least one release of Ubuntu. So, ARB could accept no new submissions after FeatureFreeze for the current dev release. But, ARB continues approving apps into the current release right up to release day of the dev release.

  • Backports are not visible by default, so people would have to manually enable each ARB app individually. (This could be handled by a backports feature that allows some new backports to be visible by default.)
  • Lenses and Scopes run on completely different APIs from one Ubuntu release to the next, so the backports model doesn't really work (most backports would be completely different code than the current dev release).

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

  • A large number of possible conflicts could be avoided if we check package contents against:
    • $release Contents*.gz files (for stable releases they exist and don't change)
    • Contents*.gz files for -updates, -security and -backports, archive.canonical.com and extras (these would need to be generated).
    • One caveat would be diversions and alternatives, but they could be checked with a logic like in command-not-found.
    • An unlikely, but possible problem is: App A is accepted and ships file X, later on package B in Ubuntu proper ships new file X. Conflict!

  • Confinement is a problem not solved by the /opt requirement, but with initiatives like SecurityTeam/Specifications/Precise/AppArmorEasyprof be considered in the future.

    • Plugins such as Nautilus plugins are currently not allowed anyway. The /opt requirement just 'automatically' rules out they sneak in.

User Stories

  • Alice has developed a cool Unity lens for the stable release, but which is unfortunately not compatible with the development release. Alice would like to have the lens deployed to the stable release while she makes a different version for the development release.

    • Backports: If Alice's lens won't build on the development release of Ubuntu, it can't be "backported" to the stable release

  • Bob is super excited about today's release of Ubuntu, and decides to submit his app to it so all the new users switching from windows will be able to install it.

    • Backports: The development release's archives aren't immediately available after an Ubuntu release, so Bob's submission must wait.

  • Charles has been working diligently on making his new app work with the latest Ubuntu release, and one month after that release date his app is ready to submit to the USC.

    • Backports: Even though the development release's archives have been recently opened, they're not at all like what they will be on release

  • Diana has written a small fun game and wants it available for download in Ubuntu. She builds a very basic but functional package that fails some lintian tests around debian packaging guidelines

    • Backports: Would Diana's package need to abide by the same packaging rules as other Universe packages?

    • Extras: Packaging rules enforced by the ARB would be different from those enforced by MOTUs

More info

Previous discussion

Docs

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