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

[Joerg Barfurth]

Jeremy White wrote:
>>   ./install-some-software.sh --prefix=/mnt/shared
>>
>> (or PREFIX=/mnt/shared ./install-some-software.sh, if you prefer).
> 
> Um, you've just added  '--prefix' to the mix; that does
> not exist in any specification.  You're saying that all application
> installers must respect an environment variable of PREFIX
> or a flag of --prefix?
> 

No. Were you suggesting that all installers must be able to install to 
different prefixes according to XDG_DATA_DIRS?

I only suggest here, that installers that support relocation should do 
so with a 'prefix' mechanism rather than XDG_DATA_DIRS.

Installers that don't support relocation will have chosen a location to 
install to, which means they implicitly chosen a hard-coded prefix.

What I meant to suggest, is that installers should generally install 
desktop integration files into places in their prefix. And then we 
probably need a simple way to make this take effect in the desktop 
globally. But that last part should be a separate (and optional) step.

This seems to match the admin desire to install into a sharable, 
mountable, optional location. It's bad if you have global desktop files 
point to an optional location that isn't there today. And it is just as 
bad, if you can't have menu integration for an application installed 
into a mounted directory, because that installation happened on another 
machine. Thus installing the bits and integrating into the local system 
must be separable activities.

One more note: installers that have no notion of a prefix at all are 
probably just the moral equivalent plain tarballs and can't install 
out-of-prefix anyhow.


> I'm not opposed to the addition of a XDG_WRITE_DATA_DIRS specification
> addition to the basedir-spec.  In fact, I would assert that Waldo
> is essentially saying that XDG_WRITE_DATA_DIRS exists and is
> always hard coded to /usr/share:/usr/local/share.
> 
> I still feel that having XDG_DATA_DIRS be both read and write can
> be a reasonable spec, but I can see rational arguments against.
> 

I'm not so sure that is a good idea. I think putting files into the 
application prefix and then registering that location through a file in 
/etc (or through invocation of a system utility) in much better suited 
to provide flexibility and manageability (and conform to the letter and 
spirit of the FHS).

- Joerg

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