installation into /opt

[Allison Randal]

Laney mentioned this to me a few weeks ago, and it's been steeping in
the back of my mind. This isn't really a request for change, it's more
of a sanity check:

We require packages submitted to the ARB (for the Extras archive) to
install everything into /opt/extras.ubuntu.com/<packagename>. (With an
exception for .desktop files and similar pieces that don't work at all
in /opt.)

The developers submitting to the ARB are mostly new developers, who have
never packaged before. So, the first thing we're teaching them is the
wrong way to package, putting files in all the wrong places. And, it's
substantially harder than putting files in the right places, because the
tools aren't adapted to handle it (for example, we always manually hack
debian/rules to make sure the standard dh_installdocs target doesn't
run, because it installs all the standard docfiles in the *standard*
locations).

We've also started getting volunteers to help the ARB with packaging
(for those apps where the developer isn't ready to take on packaging
yet, or needs some help). Most of the volunteers here are pretty new to
packaging too, and the first thing we're teaching them is the wrong way
to package.

We also encourage all packages submitted to Ubuntu through any channel
to submit upstream to Debian. So, after putting that work into
customizing the install location to /opt, we turn around and ask them to
undo it.

One idea behind installing in /opt is that it would make reviews faster,
because files would be out of the way of packages from the ordinary
archive, binaries not in the PATH, etc, and so the packages wouldn't
need such careful review. But, when we receive a submission that's
already been packaged well in the standard way, we have to bounce it
back to the developer to change over to /opt, or manually fix it up
ourselves. And when we receive a submission that hasn't been packaged
yet, it takes maybe an hour to package it using dh_make (which sets
everything up for the standard paths), and then another 3 hours to get
all the bits working in /opt (or more if we run into a bug with
installation in /opt, which we still do regularly). It ends up being
substantially slower to process these apps.

Another idea behind installing in /opt was to keep extras clearly
separate from the main, universe, etc archives. But now we're treating
it more as a "gateway" into Debian/Ubuntu, the first stepping stone on a
longer path.

Another idea was to prevent namespace conflicts with packages in the
standard archive, for both libraries and binaries. But, if apps are
likely to go on to Debian/Ubuntu anyway, we have to review them with the
standard install destination in mind, and make sure they don't conflict
with any existing apps.

Another idea was the security benefit of having these apps outside the
PATH. But, we are executing the binaries for these apps (through the
.desktop file), which is the greatest security risk, and requires a
security review of all features. Having the binary in the PATH provides
another way to start the code running, but doesn't run different code.


Weighing the pluses and minuses, is installation in /opt still the best
way to go? It's primarily the "training new developers" part that gives
me pause, but a little external reassurance would go a long way to quiet
my doubts.

Thanks,
Allison