for tomorrow's meeting: ARB exception proposal

[Martin Pitt]

Hello Allison,

Allison Randal [2010-11-16 11:20 -0800]:
> > 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.

I wouldn't be terribly happy about it, but since those packages will
undergo manual checks from the ARB, we can reasonably prevent
clobbering existing app names or name collisions, so personally I
could live with it as a maverick exception.

However, I don't want to give my +1 here until we actually have a
long-term solution for that? Once everythign is in /opt/, we would
need a way to add those paths to user's $PATH somehow? Do we have a
solution for that?

Or should that rather be a reason to not ship non-.desktop-ish
applications in extras at all? (Which would be a fair compromise
IMHO).

> 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.)
> [...]
> Our best alternative is to have the ARB manually modify the developer's 
> source packages to add .install files forcing an /opt install.

That'd be a workaround. I do appreciate that we shouldn't backport
tool chain changes to maverick, but perhaps we could work around this
in quickly in maverick?

> /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.

Noted. However, shouldn't our packaging system already prevent that?
If none of the files conflict (just install in the same dir) it won't,
but that might be something we could add to dpkg (check if your
package to be installed is for /opt/foo, while that directory already
exists).

OTOH such a conflict would also mean that the user tries to install a
different version of that software through software-center. In that
case we would actually want the older ones to be overwritten.

> 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.

Since we went through great lengths to separate these packages from
Ubuntu itself, I'd rather not call it /ubuntu/. 

> 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

IANAL, but since that's already common practice for third-party
packages (like the .debs for Acrobat reader), I would think that it
would be okay. /usr/share/doc/<package>/copyright is a Debian
convention, not a requirement from any license.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)