Menu-spec update (Was: [Patch] Update 'How to' to clarify computation of datadir)

Joerg Barfurth Joerg.Barfurth at Sun.COM
Wed Mar 22 17:04:50 EET 2006

Waldo Bastian wrote:

>> Or should we just clarify datadir   
>> to mean $prefix/share and sysconfdir to mean $prefix/etc, or /etc when
>> $prefix is /usr?

> That just moves the problem to figuring out what $prefix is supposed to be. 
> And if an application installs to /opt/myApp/ in accordance with LSB then it 
> can't use /opt/myApp as $prefix because that's unlikely to be included in 

Well, looking at the FHS that seems to be what is intended. ISV software 
that installs into /opt/myApp, then binaries (in /opt/myApp/bin) aren't 
in the default PATH, its man pages (in /opt/myApp/share/man) aren't in 
the MANPATH, etc. without the system administrator or the user including 
them with explicit (manual) action. From a systematic POV the same 
should hold for desktop integration files: they aren't in the default 
search pathes unless an admin or user explicitly adds the new location 
to XDG_DATA_DIRS (and possibly XDG_CONFIG_DIRS).

Locally built and installed software goes into /usr/local, so will be in 
the default PATH if /usr/local/bin is, and will be in the menus through 

>> Should this all be done in a spec outside the Menu 
>> Spec? Don't "we" already do this outside the Menu Spec, in the Linux
>> Standards Base Filesystem Hierarchy Standard document?
> Well, the closest thing the FHS describes is where to store man-pages 
> (/usr/share/man) 

It [*] also says man pages for optional packages should go into 
/opt/<package>/share/man ...

That all said, there should be a specification for how ISVs can automate 
making their applications available globally without requiring manual 
user or admin intervention. I'm not sure what the best approach is here, 
though. Some possibilities include symlinking the package specific files 
into a well-known directory (under /opt/share or /usr/local/share) or a 
file in /etc that lists directories which should be included in the 
XDG_.._DIRS. Of course any XDG...DIRS-modifying method requires user 
sessions to be restarted in order to pick up the changes:-( And of 
course for such a method there should be a way to switch this off on 
systems where admins want to stay in control and prefer manual changes.

Maybe the best solution is a system-provided menu-integrate script, that 
can be pointed at /opt/myApp and then follows the solution the OSV prefers.

[*] I'm referring to the general FHS from <> 
  I don't know if LSB adds much specific interpretation, but then I 
don't think we ought to mandate a linux-specific interpretation on fd.o.

- Joerg

PS: Note that these are completely my personal musings on this matter.

Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
 >>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at
Thin Client Software

More information about the xdg mailing list