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 -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
