OptRequirement

Differences between revisions 20 and 21
⇤ ← Revision 20 as of 2012-04-27 13:16:51 →
Size: 5553
Editor: dholbach
Comment:
← Revision 21 as of 2012-04-27 13:17:41 → ⇥
Size: 5557
Editor: dholbach
Comment:
Deletions are marked like this. Additions are marked like this.
Line 27: Line 27:
=== 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?

=== 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.
Line 37: Line 48:
=== 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.

=== 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?

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.

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?

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!
      • Could this be avoided (or at least be made much less likely) with having a "no general-purpose file/directory name" policy?

  • 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.

More info

Previous discussion

Docs

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