Menu-spec update (Was: [Patch] Update 'How to' to clarify computation of datadir)
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
It [*] also says man pages for optional packages should go into
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 <http://www.pathname.com/fhs/>
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.
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 sun.com
Thin Client Software
More information about the xdg