Michael Hall wrote: > On 09/05/2012 02:08 PM, Emmet Hikory wrote: > > Regardless of our final decision with regard to the implementation > > limiting the impact on users of potentially malicious automatically > > reviewed applications, I think we ought continue to make efforts so > > that our tools support /opt properly. There are many existing popular > > and successful free and commercial applications using /opt today for > > other unices, and we can only benefit by reducing the porting effort > > for this software to Ubuntu. > > > > It's important to remember that when we say "support /opt/ properly" > what we really mean is "support /opt/extras.ubuntu.com/* properly". We > aren't just using /opt/ as an install prefix, we making a different > install prefix for every single application, and that means that every > tool is going to need to consider every install prefix for every > application that might be installed.
Actually, in the above context, I mean to add support for /opt/foo, where foo represents both arbitrary values and arbitrary levels of nesting. This can easily be used to support /opt/e.u.c/bar/, but also allows the use of /opt/getdeb.net/baz or /opt/autodesk.com/autocad/, or any other arbitrarily identified third-party install location that some software distributor wants to present to their users. In terms of runtime tool support, rather than attempting to identify all possible values of foo in applications that perform discovery, we would do better to either investigate, improve, and use tools like xdg-icon-resource to manage third-party application support, allow such packages to add paths to some consolidated virtual filesystem via some well-defined API, or other similar solution. (Yes, this is another potential source of namespace collisions, but one separated from the base filesystem, and thereby in letter (if perhaps not entirely in spirit), less likely to result in debian policy violations. > But at the same time we're not currently making those app-specific > install prefixes actual alternatives to /usr/, they don't contain > /opt/extras.ubuntu.com/{appname}/share/applications/{appname}.desktop, > or /opt/extras.ubuntu.com/{appname}/share/pixmaps/{appname}.png Right, which I would argue is an incomplete implementation of the FHS-compliant use of the /opt hierarchy. I consider our incomplete adoption and support of this to be a set of bugs (although I make no claim that these are important or even significant bugs, depending on our final determination on the implementation of application insulation). > So even if we did make all of our tools use $XDG_DATA_DIRS, and we did > include every installed Extras app in $XDG_DATA_DIRS, they still > wouldn't work because we're not making those directories behave like an > XDG_DATA_DIR should. If we took the first two steps, I do not understand why we would not then take the third, and I certainly don't understand why our failure to take the third should be interpreted as a failure of the proposition, rather than a failure of our resolve. There do exist bugs for which the simple use of XDG_DATA_DIRS is insufficient, the identification and solution to which may cause us to decide that we do not wish to include the restriction to /opt in our application insulation, but if we do decide to use /opt as part of our solution, we should by all means expect that applications built with an install path including /opt will not require different configuration of the content, simply as a result of the install location. ${INSTALL_PATH}/share/quux should have the same content in both situations, such that, for example, we may expect that /opt/extras.ubuntu.com/feathered-friends/share/applications/ would contain .desktop files that could be selectively processed by any compliant xdg-menu implementation, and, similarly, .../icons/ would contain either bitmap icons in common formats or compliant themes (or partial themes) to support those .desktop files. -- Emmet HIKORY -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel