Proposing a New App Developer Upload Process

[Emmet Hikory]

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