Lennon Cook wrote:
On 3/24/06, Waldo Bastian <[EMAIL PROTECTED]> wrote:
Just like #3, the application could install all its files within its own
prefix.
I tend to think that this is the best idea.
The problem is that it complicates things for users that simply want
newly installed applications to be in their menu. They always have to
take extra steps. As Waldo has mentioned it also may have a performance
impact (it leads to long XDG_*-DIR search pathes, requiring iterating
all those directories.
The tool could probably symlink the files
into /usr/share/applications with the option to use other locations at the
discretion of the distributor.
Leave decisions like this to the user/sysadmin/distro.
The idea of such a tool is, that it is a well-defined interface (i.e. we
fix its name and syntax), but multiple implementations are possible. The
distributor can choose to create an implementation that uses the
location of their choice. And they can even add support for
admin-provided policy. That means the admin can make this a no-op or
redirect to a special directory through a file in /etc. And the admin
can use the same tool for menu integration of bits that are already
installed in a shared location.
What happens
if, for whatever reason, the sysadmin doesn't want a particular app's
files to be in the various paths? The installer has no way of knowing
this. The policy of how to include a particular file in XDG_*_DIRS
directly affects this, and so should be an admin concern.
The implementation of the tool may provide this capability.
So I think the tool idea really provides the best of all worlds. All the
better, if there is a desktop-install tool precedent.
- Jörg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer [EMAIL PROTECTED]
Thin Client Software
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
