ext Andrew Flegg <and...@bleb.org> writes: > On Thu, Sep 10, 2009 at 16:12, Marius Vollmer <marius.voll...@nokia.com> > wrote: >> ext Andrew Flegg <and...@bleb.org> writes: >>> >>> Instead of using a fixed prefix of /opt/maemo/<path>, use >>> /opt/<package>/<trimmed path>. >> > [big snip] > > I'm not going to get into a point-by-point rebuttal of these.
Hmm, I am really in a detail-oriented "let's get this done" mode. As I said, the question of whether or not and if so how to use /opt for distribution packages is bigger than this, and I don't think we should try to answer it here. People haven't really used /opt in their packages until now, and nothing really has changed to reconsider this on a massive scale. The name "/opt" that appears in this discussions is a big giant red herring. Just pretent it really was "/space" all the time, and I hope you can see how different the discussion would have been. > But installing stuff in /opt on Maemo by third-parties isn't really > going to happen. Maybe not, but that's no reason to repurpose the whole of /opt. You could also say that Maemo will never really be multi-user, but that's no reason to get rid of /home/user. > We own the space, pretty much everything is going to be installed from > packages, and we already make all manner of assumptions in a Linux > system that there's some unique "UNIX name" for a package. Why *not* > make the one-line change to maemo-optify to make its results slightly > cleaner? Because it's not cleaner in my view, it would be an even bigger abuse of /opt than hiding things in /opt/maemo. If you really care, we can make this an option to maemo-optify, and you can use it in your packages. I will still recommend the default of just moving everything to /opt/maemo without any further distortion. >> - 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? > > ...because /opt is a hack because no-one at Nokia had the foresight to > imagine that users might want to install multiple applications, and > large new frameworks like Qt. The "/opt is hack" statement needs to be qualified, of course. "Moving stuff into /opt/maemo" is a hack, of course. But at least in my opinion, "Moving stuff into /opt/<package>/" is a bigger hack, and a bigger violation of the letter and spirit of /opt. *shrug* > ...because /opt is a hack which should be *embarassing*. It is! > ...because maemo-optify creating a forest of symlinks is messy, > unelegant and possibly prone to failure (see my earlier question about > Python modules and sub-directories of optified packages). If I understand your proposal here right, we would still have the same forest of symlinks, just more messy since they have a more complicated pattern. > Mainly, though, because last minute fixes shouldn't throw good design > out of the window. I don't think using /opt/<package> in distribution packages is good design. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
