quickly ubuntu templates should install apps in /opt not bin
| 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.
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?
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.
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?
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".
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.
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?
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 :)
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?
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.
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-
Quickly is currently a snapshot of trunk + my branch.
forget to put in python-support changelog:
python-support (1.0.10ubuntu3) natty; urgency=low
* movemodules, update-
- add support for --prefix
This bug was fixed in the package python-
---------------
python-
[ Didier Roche ]
* debian/
- 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/
- add man for --force-copyright
- add man for --force-rules and --prefix
python-
[ 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> 2010年11月18日 11:39:08 +0100
This bug was fixed in the package cdbs - 0.4.89ubuntu6
---------------
cdbs (0.4.89ubuntu6) natty; urgency=low
* 1/class/
- add --prefix support for pysupport by DEB_PYTHON_
* test/distutils-
- add the test to check DEB_PYTHON_
* debian/control.in:
- depends on specific version of python-support so that the test pass
-- Didier Roche <email address hidden> 2010年11月18日 11:27:13 +0100
This bug was fixed in the package quickly - 11.03-0ubuntu1
---------------
quickly (11.03-0ubuntu1) natty; urgency=low
* New upstream release
+ ubuntu-
- 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_
- support submitubuntu command to install applications in /opt
(LP: #625581)
+ ubuntu-
- 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> 2010年12月06日 10:23:14 -0500