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

[Joerg Barfurth]

cobaco (aka Bart Cornelis) wrote:

>> This installer must be non-interactive too.
> 
> as above, NOTE:
> - ask with debconf at medium priority, which means that only people who want 
> to be bothered with questions about settings like this will be bothered, 
> everyone else will get it placed in the first writeable XDG_*_DIR
> 
>>   * an RPM package that can be installed on any rpm-based system. This
>> installer must be non-interactive.
> 
> can anyone on the list confirm wether or not rpm has something similar to 
> debconf priorities?
> 

I doesn't. RPM has no support for any kind of interactivity during 
installation.

>> This supposes we can come up with defaults that work across Linux
>> distributions...
> 

Note that freedesktop.org is about free desktops on any (at least free) 
system, not specifically Linux.

> first XDG_*_DIR that's writeable seems reasonable to me, sofar I haven't 
> seen anyone saying it would be unreasonable.
> 

I think there were several arguments pointing out that this *is* 
unreasonable:

1. The XDG_*_DIR settings are user or even session specific. Thus if you 
install according to the XDG_*_DIR settings of some administrative 
session, the chosen location may be unrelated to the XDG_*_DIR of a user 
session.

2. A searchpath is unsuitable to define the target of an installation. 
The result would be too ill-defined. How would this deal with currently 
unavailable mount points or network shares? How to diagnose wrong 
behaviour (or even define correct behaviour), when executing an 
installation twice (by different users or with different histories) may 
lead to a different result without a visible clue (like an explicitly 
set parameter).

3. It couples two unrelated things. What should be done, if the 
XDG_*_DIR a users needs for software installation (e.g. to run some 
installation tool) is different from the XDG_*_DIR of the target user 
configuration. (This is issue 1. from a reverse angle).

This is about as unreasonable as defining that end user binaries should 
be installed into the first (writable) directory in the installing 
user's PATH.

The reasonable solutions I can see are:

A. Install into the installation prefix of the application. If that 
doesn't integrate into the global menu, then it is the responsibility of 
the sysadmin to perform that integration.

B. Do A. and then run a well defined tool (akin to update-mime-database) 
to perform the integration. Distros can customize their version of this 
tool to honor their preferred locations and/or sysadmin policy.

C. Always install into /usr/local/share. If a distro or admin chooses to 
change XDG_DATA_DIRS not to include /usr/local/share, then they 
consciously decide against automatically getting new apps into the menu. 
Arguably this is against the spirit of the FHS and prefix-oriented 
installation, because it misuses /usr/local by mixing data for /opt (or 
whereever) -installed software into this location. Usually global 
registration of a new service takes place in /etc. OTOH it has been 
common existing practice to make files globally available by installing 
(or symlinking) them into some place under /usr.

D. As a variation of the preceding: Install into the prefix and them 
symlink into /usr[/local]/share.



-- 
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:joerg.barfurth at sun.com
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/