for tomorrow's meeting: ARB exception proposal

[Allison Randal]

On 11/16/2010 08:30 AM, Martin Pitt wrote:
> = .desktop files =
>
> This wasn't discussed extensively, but some comments indicated that
> making an exception for those for maverick should be okay. (Hasn't
> been officially approved yet, though)

Noted.

> = Python binaries =
> Is that actually an issue? They could all live in /opt/<packagename>/,
> we are mostly concerned about user-facing apps which ship a desktop
> file?
>
> Do we have actual cases where those extra packages ship command line
> applications or something which needs to be in $PATH?
>
> How would people think about the (maverick only) permission to ship a
> symlink to /opt/... in /usr/local/bin?

We're not overly concerned about binaries for user-facing apps, but it's 
worth deciding now if you're comfortable with the exception. A simple 
command-line interface corresponding to a simple desktop app does seem 
like a reasonable possibility.

> = Python libraries =
>
> For maverick we could require app developers to add their application
> path directory to sys.path, and fix quickly to do that automatically.
> Would that be practical?

For Natty, Didier has fixed Quickly, cdbs, python-support, and 
python-distutils-extra to handle /opt installation. But we can't 
backport those fixes to Maverick. (We can ignore Lucid, as we aren't 
targeting these apps to Lucid.)

The core problem is that cdbs and dh_support (as shipped in Maverick) 
currently only support prefix=/usr for Python, when we need 
prefix=/opt/<appname> or prefix=/opt/<vendor>/<appname>.

Our best alternative is to have the ARB manually modify the developer's 
source packages to add .install files forcing an /opt install. It's a 
little labor intensive, but we were already prepared to do more work for 
the Maverick ARB reviews, and there are really only 4 proposals in our 
queue anyway. We'll test this strategy on the existing applications in 
the queue before the next TB meeting.

> pyc files are just a "nice to have", so we could ship maverick
> packages without them.

Yes, we can skip them for Maverick packages, the small loss in speed 
isn't a big problem for the lightweight apps we're considering. Python 
version symlinks we can probably also skip (since it's a custom app lib 
directory).

> I didn't quite get why people asked for a vendor prefix in /opt/, like
> /opt/ubuntu. What would this give us? AFAIK it wouldn't address any of
> above problems, and just additionally require LANANA registration,
> etc.?

/opt is a common location for user-compiled applications and libraries, 
so even though we're not using it for any Ubuntu packages, there is a 
substantial risk of namespace collision. Also, the /opt/ubuntu vendor 
prefix (or whatever name) ultimately gives us a sensible location for 
installing .desktop files, and other files we want to move from the 
standard paths to /opt.


An added question came up while I was pinning down the Python libs 
install of whether installing the legal data and package information 
under /opt instead of /usr/share/doc/<appname> is legal, or will be 
visible to other parts of the system. Legally it should be fine as long 
as we clearly state that /opt/<vendor>/<appname>/doc is the specified 
location for license files for lightweight apps.

Allison