OptRequirement

Revision 24 as of 2012-04-27 15:15:31

Clear message

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. All these exceptions have to be approved by the TB.

Because of this we are facing huge problems, which stifle the success of Ubuntu as an app platform: Our toolkits, checking tools and frameworks are stream-lined to install files into /usr, not into /opt. Also is all documentation on the internet is about /usr. If you want to get your app into Ubuntu, you have to either special-case where you look for files or maintain separate versions of your code.

All of this results in the ARB spending vast majority (probably 90%) of time on extra work: educating submitters, fixing build system and packaging and rejecting otherwise likely good applications. This is very demotivating, both for ARB members and for app authors.

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.

Expiring apps

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.

Options

If we don't move at all, we could:

  • keep using extras.u.c with the opt requirement or
  • get apps into backports

If we decide to relax the requirements or otherwise solve the problems, we could:

  • keep extras.u.c or
  • try to integrate apps into Ubuntu proper

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