OptRequirement

Differences between revisions 17 and 18
⇤ ← Revision 17 as of 2012-04-25 14:43:46 →
Size: 3555
Editor: dholbach
Comment:
← Revision 18 as of 2012-04-25 16:49:14 → ⇥
Size: 3622
Editor: dholbach
Comment:
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
= Background =
Apps which go to the AppReviewBoard, currently have the requirement to install files into /opt.		 = 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''.
Line 9: Line 9:
== Rationale ==
 * '''Avoiding conflicts:''' Installing files into a separate location on the file system helps to avoid file conflicts.
 * '''(Future) confinement:''' In the future this would allow us to more easily confine apps.(?)
  * Currently possible already: through directory separation things like (broken) plugins are impossible to do.
 * '''FHS definition:''' `/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.
Line 15: Line 11:
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 extras work''': educating submitters, fixing build system and packaging and rejecting otherwise likely good applications.



= Solutions =
 * 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 =
Line 30: Line 43:

= Exceptions =
Exceptions to the /opt requirement need approval by the TB on a case by case basis. Currently unity extensions and .desktop file are allowed.

= Problems =
 * Our toolkits, checking tools and frameworks are stream-lined to install files into /usr, not into /opt.
 * General documentation on the internet is all 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.
 * ARB spends vast majority of time educating, fixing and rejecting.

= Solutions =
 * 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.

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 extras work: educating submitters, fixing build system and packaging and rejecting otherwise likely good applications.

Solutions

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