[maemo-developers] Considering /opt and MyDocs in your packages

[From: Marius Vollmer]

ext Andrew Flegg <andrew at bleb.org> writes:

> I've a suggestion for Marius, after some discussion on #maemo. This
> suggestion should make maemo-optify more compatible with how
> Maemo-specific applications, aware of /opt, may use it (and closer to
> how /opt is traditionally used in upstream Linux).
>
> Instead of using a fixed prefix of /opt/maemo/<path>, use
> /opt/<package>/<trimmed path>.

Hmm.  My arguments against this are:

 - The names /opt/<package> do not belong to the distribution, they are
   for things that are _not_ in the distribution.  I.e., a Debian
   package called matlab has no license to install into /opt/matlab.

 - We are not trying to clean up the filesystem, installing into
   /usr/lib would be perfectly fine if only there would be enough space
   there.

 - Now, cleaning up the filesystem is a good goal, but it can be done
   independently from this space-saving struggle.  By all means, propose
   and implement ways to clean up the filesystem.  In my opinion,
   installing distribution packages into /opt/<package> might look
   clean, but it is not a good idea.  That opinion is not very strong,
   but I don't want to make the space saving here dependent on resolving
   this argument.

 - The /opt/maemo/ location moves the whole mess cleanly out-of-sight of
   all the naturaly inhabitants of /opt.  It's unlikely that other
   software wants to install into /opt/maemo.  I would prefer /space
   over /opt/maemo, but I also don't want to stirr up the waters more by
   proposing yet another change.

   Actually, the maemo-optify scripts could be changed to use
   /home/maemo/ instead of /opt/maemo... hmmm.... they would need to be
   called maemo-homeify then, of course.

   Anyway, for me, the "/opt" location is a red-herring.  We are not
   using it because we want the FHS semantics of it, we are just using
   it because that's the first thing that came into someones mind, the
   train started rolling, and I made up my mind too late about this all.

 - Computing the <trimmed path> from <path> is an extra complication,
   and we must make sure that no collisions happen.  It's doable of
   course, but in the light of the arguments above, why bother?