The problems of requiring /opt

[Elliot Murphy]

On Fri, Sep 24, 2010 at 12:28 AM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> On Wed, 2010-09-22 at 11:47 +1200, Andrew Mitchell wrote:
>> Hi all,
>>
>> I was hoping to get this discussed before the policy was published, but
>> no such luck :)
>>  From what I can see, it is not practical to require or suggest that
>> packages use /opt for all files given our lack of support for it in
>> development tools. The target audience for the post-release apps process
>> is developers who have relatively simple applications & who do not want
>> to spend most of their time trying to get the packaging right, yet none
>> of our common packaging tools make installing into /opt easy.
>>  Quickly creates a packaging template that is extremely simple, but with
>> the use of CDBS, is non-obvious how to change it to install anywhere but
>> the default paths. This will need to be changed at some point if we are
>> wanting people to use it to create packages, and I don't think this can
>> be done in time for maverick with the current freezes for release.
>>  As well as quickly, I believe that we'll get a few submissions of
>> packages that have been done 'manually' or with dh-make, and we do not
>> currently have documentation for people to look at for changing their
>> packaging to place files into /opt.
>>  For proper desktop integration, we would need to have the menu looking
>> for .desktop files in /opt, the panel looking for applets there, all of
>> which I believe have not been changed for maverick.
>>  In short, I hope that we can change the packaging requirements to drop
>> the need to use /opt, at least for this release.
>>
>> Thanks,
>> Andrew
>
> I completely agree with the above.
>
> It also would generally mean that whoever already packaged something in
> a PPA would have to re-update/fork the packaging to comply with the ARB
> rules.
>
> I'm not really sure to see what's the improvement (even if everything
> was working fine) to having these packages in /opt rather than anywhere
> else on the system.
> These softwares are still going to be managed by APT, so as long as they
> don't divert or conflict with existing files (which we'll check before
> accepting any package), apt can still list and remove these, having them
> in /opt only adds complexity from my point of view.
>
> What's important is to be very easily able to list these packages and
> making sure that they won't conflict with anything in the archive or
> make anything that's currently in the archive behave any differently
> once the package is installed.

I apologize for the lateness of my reply. I too would like to have the
/opt requirement dropped for applications delivered onto Maverick
post-release. Since we probably need to approach the tech board for
this requirement to be changed, are there any other requirements that
we want to have clarified or amended?

I would like the ability to waive some of the packaging requirements
that we would normally enforce when reviewing a package for Debian or
Ubuntu Universe, such as having man pages, and having the
debian/copyright file filled out. I expect this part may be more
controversial.

My rationale on debian/copyright is that I would like the apps
delivered via the ARB process to be subject to the same Terms of
Service that are used for providing packages via PPAs:
https://help.launchpad.net/PPATermsofUse, and that the developer may
fill out debian/copyright but is not required to.

What do others think? I think we should approach the technical board
soon for approval on changing items which we have broad agreement on,
and discuss at UDS any policy changes that are controversial.
-- 
Elliot Murphy | https://launchpad.net/~statik/