quickly ubuntu templates should install apps in /opt not bin

Bug #625581 reported by Rick Spencer
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Quickly
Fix Released
High
Unassigned
python-distutils-extra
Fix Released
Undecided
Unassigned
cdbs (Ubuntu)
Fix Released
Undecided
Unassigned
python-distutils-extra (Ubuntu)
Fix Released
Undecided
Unassigned
python-support (Ubuntu)
Fix Released
Undecided
Unassigned
quickly (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

A typical Quickly app would be more appropriate in the /opt than /bin according to discussion on @u-d.

Changed in quickly:
importance: Undecided → High
Revision history for this message
Neal McBurnett (nealmcb) wrote :

The conversation referred to has subject line "Re: Request For Candidates: Application Review Board"
which currently has about 122 messages, started 2010-08-09, and continues. The underlying topic has changed several times.

We may have consensus that applications destined for the new PostReleaseApps section of the repository should be deployed in /opt.

But Quickly has been used for regular apps in the distro for some time now, and changing where they are deployed would seem problematic.

So I would think the feature request should be restricted to apps which are targeted for PostReleaseApps.

Is support for PostReleaseApps also a new feature, or an existing option in Quickly?

Revision history for this message
Rick Spencer (rick-rickspencer3) wrote :

We will consider carefully how to implement this. For newly created applications, I don't think that installing in /opt or /bin really makes a different to the developer or to the user experience, but we should confirm that before we make the change for new apps.

For existing applications, I think changing them to use /opt instead of /bin if you want to get your app in through the new apps process should be easy for developers to do as well.

I think that "quickly package" may need to change to support this, in which case, it make impact existing apps. We'll think through it before we make any changes, and assure that we don't break anyone.

Revision history for this message
Shane Fagan (shanepatrickfagan) wrote :

I think it really depends on where the apps are coming from really. If they are in a repo like main or universe /bin is fine but where should apps from ppas or the new apps repo go?

Revision history for this message
Allison Randal (allison) wrote :

The two most common types of apps created from Quickly are local apps not intended for distribution, and apps intended for the PostReleaseApps process. Both of these make sense in /opt. Some developers will go on to create apps intended for regular distribution, but by the time they get to that, they'll have more experience with Quickly so they'll have an easier time following the steps to change the install location. Basically, it's about picking sane defaults for the "easy on-ramp".

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

I'm not sure that the debian policy take care of apps in /opt. It's some kind of violation of the FHS guidelines for a package, only totally make sense for an unpackaged applications.

Futhermore, this introduce tons of issues:
/opt is not in the PYTHONPATH by default, /opt/bin/ is not in the PATH as well…

@Allison: when you don't want to deploy, you can still use the non packaged version, which install in /usr/local as every configuration time do.

Revision history for this message
Stefano Palazzo (stefano-palazzo) wrote :

There doesn't seem to be much interest in this.

A simple piece of documentation on how to change your application post-creation so that it installs in /opt (perhaps on how to make your application compatible with the AppReview process in general) would, in my opinion, solve this issue.

I am, at the moment, not confident to sit down and work on something serious - expecting it to land in extras, just to find out later that it's near impossible to have my quickly application in /opt while preserving all the quickly-goodness. This is exactly what Quickly is for.

PS:
We are talking about AppReview here, aren't we?

Revision history for this message
Shane Fagan (shanepatrickfagan) wrote :

Im on the appreview board and its a requirement for the moment to use /opt but we are putting it off till quickly uses /opt by default which isnt an easy thing to do. So there is interest in it :)

Revision history for this message
Stefano Palazzo (stefano-palazzo) wrote :

So, if I start work now, will I later be able to easily convert my application to install in /opt, or will I have to do it all manually, and potentially break all the Quickly-goodness? Would it be ridiculous to ask for a sort of "promise" that my application will convert easily, before i spend a lot of time and effort developing with Quickly?

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

We will try to be as transparent as possible for exist Quickly applications.
The /opt installation should be looked very deeply to get the right option to choose. I think we will have it ready by the end of next week.

Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

Ok, got a first version which enables installing in /opt with a new command "quickly submitubuntu". I think we should use a dedicated command like that making some automation (is currently very similar to quickly release, so refactoring will be needed), that sends an emails or whatever to the application review board.

This needs new quickly, cdbs, python-disutils-extra and python-support I've pushed to my ppa (https://launchpad.net/~didrocks/+archive/ppa) as I want some testing on the changes before real test to natty (if it goes wrong, it can break every python application installation :)).

Quickly is currently a snapshot of trunk + my branch.

Changed in python-distutils-extra:
status: New → Triaged
Changed in quickly:
status: New → Triaged
Changed in cdbs (Ubuntu):
status: New → Triaged
Changed in python-distutils-extra (Ubuntu):
status: New → Triaged
Changed in python-support (Ubuntu):
status: New → Triaged
Changed in quickly (Ubuntu):
status: New → Triaged
Revision history for this message
Didier Roche-Tolomelli (didrocks) wrote :

forget to put in python-support changelog:

python-support (1.0.10ubuntu3) natty; urgency=low

  * movemodules, update-python-modules, debhelper/dh_pysupport:
    - add support for --prefix

Changed in python-support (Ubuntu):
status: Triaged → Fix Released
Changed in python-distutils-extra:
status: Triaged → Fix Committed
Changed in quickly:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package python-distutils-extra - 2.23-1

---------------
python-distutils-extra (2.23-1) unstable; urgency=low

  [ Didier Roche ]
  * debian/local/python-mkdebian: (LP: #625581)
    - add --force-rules to force the rules file to be recreated
    - add --prefix to force a prefix other than /usr for installing your python
      modules
  * debian/local/python-mkdebian.1:
    - add man for --force-copyright
    - add man for --force-rules and --prefix

python-distutils-extra (2.22-4) unstable; urgency=low

  [ Barry Warsaw ]
  * When the environment has $PYTHONPATH in it, we still need to prepend
    oldcwd in test/auto.py, so that the DistUtilsExtra package can be
    found. (LP: #670188)
 -- Martin Pitt <email address hidden> Thu, 18 Nov 2010 11:39:08 +0100

Changed in python-distutils-extra (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cdbs - 0.4.89ubuntu6

---------------
cdbs (0.4.89ubuntu6) natty; urgency=low

  * 1/class/python-distutils.mk.in, 1/class/python-module.mk.in: (LP: #625581)
    - add --prefix support for pysupport by DEB_PYTHON_PREFIX_ARG
  * test/distutils-9.sh:
    - add the test to check DEB_PYTHON_PREFIX_ARG usage
  * debian/control.in:
    - depends on specific version of python-support so that the test pass
 -- Didier Roche <email address hidden> Thu, 18 Nov 2010 11:27:13 +0100

Changed in cdbs (Ubuntu):
status: Triaged → Fix Released
Changed in python-distutils-extra:
status: Fix Committed → Fix Released
Michael Terry (mterry)
Changed in quickly:
milestone: none → 11.03.0
Michael Terry (mterry)
Changed in quickly:
status: Fix Committed → Fix Released
Changed in quickly (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package quickly - 11.03-0ubuntu1

---------------
quickly (11.03-0ubuntu1) natty; urgency=low

  * New upstream release
    + ubuntu-application-template:
      - tutorial command reference 4.4 glade should be design (Tony Byrne)
        LP: #661699
      - refresh the branding to the new ubuntu brand (Daniel Fore)
        (LP: #666557)
      - Support self.ui.label1 syntax
      - Support auto-connection of signal handlers named widget_signal_event()
      - support submitubuntu command to install applications in /opt
        (LP: #625581)
    + ubuntu-application-template and derivatives:
      - Fix apport code to not fail when lp-project name changes
      - Fix apport test to run cleanly by always upgrading from 0.3 to 0.4
        template (test was originally written to test that upgrade)
      - Add many tests
      - Provide mallard-formatted starter help files (Tony Byrne)
      - Fix 'add dialog' to rename dialog name with dashes correctly
      - Add 'add help-guide' and 'add help-topic' (Tony Byrne)
      - Support custom licenses better by noticing when they are being used
      - add QUICKLY_EDITOR variable to override SELECTED_EDITOR or EDITOR
        if we want a dedicated editor for Quickly (Dennis Craven)
      - regenerate debian/copyright at each quickly release/package
        (LP: #656943)
      - When getting Launchpad credentials, only allow choosing full access
      - Cleanup various help descriptions to be more consistent
    + common:
      - Reorganize tests to be easier to run as a group (./test/run.sh)
      - quickly quickly should remove *.pyc files as commands are imported
        (LP: #658710)
      - If not running under X, use nano instead of gedit as fallback editor
 -- Michael Terry <email address hidden> Mon, 06 Dec 2010 10:23:14 -0500

Changed in quickly (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.