ext Andrew Flegg <and...@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? _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
