for tomorrow's meeting: ARB exception proposal

[Allison Randal]

On 18/11/10 12:19, Martin Pitt wrote:
> 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.

After trying it out on the packages in the ARB queue, I don't think we
need an exception here, we can put binaries in /opt now.

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

I'd go half-way and say it's fine to include non-.desktop-ish binaries,
but they won't be in the $PATH.

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

Unfortunately, quickly depends on cdbs and python-support, so we can't
fix it in quickly without modifying all the relevant packages (or
reimplementing those features from scratch, which seems a waste).

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

We can look this into for future tools development.

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

In the ARB spec currently, we want it to throw an error and refuse to
overwrite, but that could change in the future.

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

The ubuntu-devel list proposal was /opt/extras.ubuntu.com/, can we get a
final say on that from the Tech Board today?

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

Yes, I think it will be fine with a small mention in the ARB documentation.

Allison