The problems of requiring /opt

[Stéphane Graber]

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.


-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/app-review-board/attachments/20100924/12d97ec2/attachment.pgp