Menu spec update (summary; closure?)

[Jeremy White]

>>>  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: 
> http://lists.freedesktop.org/archives/xdg/2006-February/007746.html

Yes; that is a sound objection; using the first writable directory
is imprecise.

> 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 
> already. 

We're separately working on the xdg-utils package [1], 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.

<grin>

Cheers,

Jeremy

1.  http://webcvs.freedesktop.org/portland/portland/xdg-utils/

    description is here:
http://webcvs.freedesktop.org/portland/portland/xdg-utils/README?rev=1.1&view=markup