Menu spec update (summary; closure?)
jwhite at codeweavers.com
Fri Mar 24 03:21:35 EET 2006
>>> 1. My proposal to specify that the first writable
>>> directory in XDG_*_DIRS be used.
> The objections to this are probably best explained by Bart in this mail:
Yes; that is a sound objection; using the first writable directory
> The primary rationale being that this is the location that works today.
> The drawback is that users can't influence it. Now, there is no reason why a
> user shouldn't be able to inform an installation tool to use another
> location, it's just that we need to provide guidance on what to do by
> default. The wording can be changed to reflect that more clearly.
(commenting on this on #4, below)
>>> 3. The assertion that ISVs should not be
>>> writing any files to the /usr portion of
>>> the file system.
> The biggest drawback of this IMHO is that it isn't supported by existing
> implementations. I would like to move forward without taking steps back. See
> The other drawback is that it spreads information across a larger number of
> directories which tends to make things slower. (Startup is heavily bound by
> disk IO / seeks)
Agreed. I also maintain that this is not a short term solution
and so can be considered as a separate proposal in its own right.
>>4. Introduce XDG_DATA_INSTALL to indicate where data files should be
>>installed and use /usr/share/ otherwise.
> Just as a user can change where an RPM gets installed or an
> autoconf-configured source package. However, it's not within the scope of
> this spec to specify what kind of command line options rpm or autoconf (or
> custom install scripts) take to specify the install prefix, why should it
> specify a way for telling package tools where to install its data files?
I'm comfortable with this option. Since there is no
existing implementation, and no impetus for anyone to build
a system with XDG_DATA_INSTALL, then I see that this will fall back
nicely to option #2.
Of course, then the next question is - is it just one directory
(say /usr/local/share), or a colon separated set of paths?
>>5. Mandate a lsb-install like tool (desktop-file-install ?) to
>>register .desktop files with the menu system without the need to specify
>>where they should be installed to (and leaving the actual location where
>>they end up implementation specific)
> Just like #3, the application could install all its files within its own
> prefix. The tool could probably symlink the files
> into /usr/share/applications with the option to use other locations at the
> discretion of the distributor. It doesn't provide a standard way for users to
> tell where their data files should be installed to, although an
> implementation could chose to follow #4.
> I wanted to say that a drawback is that this tool doesn't exist yet on current
> distributions, but "desktop-file-install" seems available on most distros
We're separately working on the xdg-utils package , with some
hope that they could serve this purpose (at least from a practical
stand point, perhaps not from a standard).
That's part of my impetus for wanting to button this down.
> Take a deep breath, look at the available options once more and rinse & repeat
> till we find concensus.
description is here:
More information about the xdg