Menu spec update (summary; closure?)

Waldo Bastian bastian at
Fri Mar 24 01:19:13 EET 2006

On Thursday 23 March 2006 09:14, Waldo Bastian wrote:
> On Thursday 23 March 2006 06:33, Jeremy White wrote:
> > Okay, so this is my summary of this thread.
> >
> > The problem is that there is no specified place to write system
> > wide data files (like menu files).  Reference this page in the
> > basedir-spec:
> >
> >
> >
> > Reading is clear; writing user specific files is clear;
> > writing system wide files is not mentioned.
> >
> > AFAIR, there are three competing proposals to address this:
> >
> >   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:

Now, if we document that XDG_*_DIRS serves this purpose as well, it will 
become something that admins can take into account but it remains a bit hacky 

> >   2.  Waldo asserts that the spec was always intended to be hard coded
> >       to either /usr/local or /usr.  This is now committed.

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.

> >   3.  The assertion that ISVs should not be
> >       writing any files to the /usr portion of
> >       the file system.
> >
> >       This would require the menu spec be updated to
> >       specify some way of allowing XDG_DATA_DIRS
> >       to be expanded dynamically; probably requires
> >       a new config file, which in turn, probably requires
> >       all compliant environments to watch it for changes.
> >
> >       The FHS is usually invoked to argue for this.

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) 

> 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?

> 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 

> > I don't know how to resolve this or bring it to closure.

Take a deep breath, look at the available options once more and rinse & repeat 
till we find concensus.

Linux Client Architect - Channel Platform Solutions Group - Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the xdg mailing list