[Portland] RE: Portland: xdg-utils

[Bastian, Waldo]

[Attempt #2: Let's make it a URL]

>For your LSB F2F pleasure, please find attached the latest status of
the
>xdg-utils part of Portland.

See http://www.svn.net/bastian/xdg-utils.html

>Note that the current approach requires an application to make multiple
>calls to xdg-icon, xdg-desktop and xdg-menu. An alternative approach
would
>be to have the application install all its files to
><install prefix>/share/... first in a directory layout that is in line
with
>the various XDG specs and then have a command like
>"xdg-install <install prefix>/share" that will scan the directory tree
and
>then does everything that xdg-icon, xdg-desktop and xdg-menu would
>otherwise do.
>
>Pros of xdg-install approach:
>* More compatible with existing practice for installs under /usr (xdg-
>install would almost be a noop for installs to /usr)
>* Would make it easier to symlink files instead of copy (xdg-icon &
friends
>could also symlink although people might not expect that)
>* Would be easy to include support for man pages (by adding directory
to
>/etc/man.config for example, see also LSB bug 858 and lsbinstall
>discussion) or fonts.
>
>Cons of xdg-install approach:
>* Concept might be harder to grasp than the individual commands
>* Introducing new functionality and preserving a smooth upgrade path
seems
>to be harder: what to do when the share directory contains unknown
files?
>Fail? Ignore? With individual scripts it will be obvious when e.g. a
future
>"xdg-man" is not available and it is trivial in that case to fallback
to a
>version that is supplied alongside with the application.
>* Might be difficult to find out what was added if <install prefix> is
>shared with other applications. (worst case: /usr)
>
>Waldo Bastian
>Linux Client Architect - Client Linux Foundation Technology
>Channel Platform Solutions Group
>Intel Corporation - http://www.intel.com/go/linux
>OSDL DTL Tech Board Chairman