[Bug 1197037] Re: applications should be installed in /opt, not /usr

Jamie Strandboge jamie at ubuntu.com
Mon Sep 16 15:23:16 UTC 2013


Updated the description to make clarify we are talking about the
app_pkgname (ie, the "name" field in the click manifest), not the APP_ID
that is used by apparmor, application lifecycle, etc.

** Description changed:

  Currently the SDK installs applications in /usr. This is fine for
  traditional Ubuntu packaging for now, but with the move to Click
  packages, these paths will be:
  
- /opt/click.ubuntu.com/<app-id>/<version>/
+ /opt/click.ubuntu.com/<app_pkname>/<app_version>/
  
- where <app id> is the reverse domain name. Eg:
+ where <app_pkgname> is the reverse domain name. Eg:
  com.ubuntu.developer.appdev_username.appname
  
- The above path and the format of the <app id> is finalized and used by
- apparmor, click, the click server, and application lifecycle (ie,
- desktop files). All that's left is for the SDK apps to incorporate these
- changes as needed (eg, for their readable and writable directories).
+ The above path and the format of the <app_pkgname> is finalized and used
+ by apparmor, click, the click server, and application lifecycle (ie,
+ desktop files) in various ways. All that's left is for the SDK apps to
+ incorporate these changes as needed (eg, for their readable and writable
+ directories).
  
- Note: /opt/click.ubuntu.com is the default and could change. This should
- be totally transparent for the SDK though.
+ Note: /opt/click.ubuntu.com should not be harcoded anywhere. While it is
+ the current location, it is configurable and one of several locations
+ for click packages on the system.

** Description changed:

  Currently the SDK installs applications in /usr. This is fine for
  traditional Ubuntu packaging for now, but with the move to Click
  packages, these paths will be:
  
  /opt/click.ubuntu.com/<app_pkname>/<app_version>/
  
  where <app_pkgname> is the reverse domain name. Eg:
  com.ubuntu.developer.appdev_username.appname
  
  The above path and the format of the <app_pkgname> is finalized and used
  by apparmor, click, the click server, and application lifecycle (ie,
- desktop files) in various ways. All that's left is for the SDK apps to
+ desktop files) in various ways.  The "app_pkgname" is set via the "name"
+ field in the click manifest. All that's left is for the SDK apps to
  incorporate these changes as needed (eg, for their readable and writable
  directories).
  
  Note: /opt/click.ubuntu.com should not be harcoded anywhere. While it is
  the current location, it is configurable and one of several locations
  for click packages on the system.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1197037

Title:
  applications should be installed in /opt, not /usr

Status in [obsolete] Ubuntu QtCreator Plugins:
  Fix Released
Status in “apparmor-easyprof-ubuntu” package in Ubuntu:
  Fix Released
Status in “click” package in Ubuntu:
  Fix Released

Bug description:
  Currently the SDK installs applications in /usr. This is fine for
  traditional Ubuntu packaging for now, but with the move to Click
  packages, these paths will be:

  /opt/click.ubuntu.com/<app_pkname>/<app_version>/

  where <app_pkgname> is the reverse domain name. Eg:
  com.ubuntu.developer.appdev_username.appname

  The above path and the format of the <app_pkgname> is finalized and
  used by apparmor, click, the click server, and application lifecycle
  (ie, desktop files) in various ways.  The "app_pkgname" is set via the
  "name" field in the click manifest. All that's left is for the SDK
  apps to incorporate these changes as needed (eg, for their readable
  and writable directories).

  Note: /opt/click.ubuntu.com should not be harcoded anywhere. While it
  is the current location, it is configurable and one of several
  locations for click packages on the system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-qtcreator-plugins/+bug/1197037/+subscriptions




More information about the foundations-bugs mailing list