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

[cobaco (aka Bart Cornelis)]

On Wednesday 22 March 2006 11:25, Francois Gouget wrote:
> cobaco (aka Bart Cornelis) wrote:
> [...]
>
> > Is it really that difficult for an ISV to look at XDG_*_DIRS, check
> > which ones are writeable and pop up a question asking which one to
> > stuff their files in (or if you want a new dir)? That would still give
> > the same defaults if the environment variables aren't set.
>
> Looking at XDG_*_DIRS and checking which directories are writable is
> easy enough and essentially what Jeremy proposed. But that's not what
> the specification says an ISV should do. The new specification
> essentially says that ISVs should ignore $XDG_*_DIRS and always assume
> datadir=/usr/share and sysconfdir=/etc/xdg.

which does not seem like a good idea to me, so why are we changing the spec 
that way?

> I will note that it does have a provision for the case where /usr/share
> is not writable and suggests to write to /usr/local/share in that case.
> But I cannot see when one would be able to the latter without being able
> to write to the former since both are usually owned by root.
>
> As for asking the user where to write desktop files there are three
> problems that make it impractical:
>   * it supposes interaction with a user which makes automated RPM
> installations impossible (to cite just one example).

Firstly, given that they're already asking where to put the app itself [1] I 
don't see the problem.

Secondly in an automated install you'd simply use the defaults, and not ask 
questions:
- for deb-packages an automated install would have the debconf priority set
  differently (to critical if I rember correctly), so if you ask the
  question at the right priority it wouldn't be shown with an automated
  install, which would just use the default answer (=first writeable
  XDG_*_DIR_)
- I'm not familiar enough with rpm to know for sure, but I'd be surprised if
  there wasn't a similar mechanism for rpm-installs.
- in windows installs this usually boils down to not using the custom
  install of whatever software you're trying to install

[1] http://lists.freedesktop.org/archives/xdg/2006-February/007719.html

>   * users don't know nor care where desktop files should go.
>   * asking this sort of thing to the user is very user unfriendly.

a regular using installing something would only be able to install in his 
homedirectory in which case the spec doesn't have a problem 

-> that's bogus, as the the only case where this is a problem is when it's
   _not_ a regular user that 's doing the install, and I'd say asking (at
   non-critical priority so it can be ignored for automated installs) is a
   very adminfriendly thing to do.

> > Also I'm  not sure about the default use of /usr/share for ISV stuff,
> > LSB puts third-party things under /opt, do we really want to conflict
> > with this?
>
> We want ISVs to put their menus somewhere where they will be found by
> the desktop environment. So locations like /opt/isv_package/share don't
> qualify.

If XDG_*_DIRS is set, you can't generally make the assumption that menu 
items in /usr/share will still be included for any particular user 
(I'd assume that in most situations when you explicitly set the menu for a 
group of users it's because you do _not_ want anything in there that you 
haven't put in there explicitly, which means /usr/share/ wouldn't be 
included. I don't have any real data to back that up so YMMV)

If XDG_*_DIRS isn't set you most likely end up using /usr/local/share by 
default (when using the first writeable directory), which seems more sane 
than /usr/share as it avoids conflicts with files from the the distributor.
-- 
cobaco (aka Bart Cornelis):
    Coördinator Belgisch Skolelinux team
    Coördinator Nederlandse Skolelinux vertaling
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060322/018f1c0a/attachment.pgp