The problems of requiring /opt

[Shane Fagan]

On Sun, 2010-10-03 at 20:43 -0400, Elliot Murphy wrote:
> 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/
> 
Sounds good to me so the first step is to ask if we need TB approval I
suppose. 

--fagan