>>> 1. My proposal to specify that the first writable >>> directory in XDG_*_DIRS be used. > > > The objections to this are probably best explained by Bart in this mail: > http://lists.freedesktop.org/archives/xdg/2006-February/007746.html
Yes; that is a sound objection; using the first writable directory is imprecise. > The primary rationale being that this is the location that works today. > The drawback is that users can't influence it. Now, there is no reason why a > user shouldn't be able to inform an installation tool to use another > location, it's just that we need to provide guidance on what to do by > default. The wording can be changed to reflect that more clearly. (commenting on this on #4, below) >>> 3. The assertion that ISVs should not be >>> writing any files to the /usr portion of >>> the file system. > > The biggest drawback of this IMHO is that it isn't supported by existing > implementations. I would like to move forward without taking steps back. See > > The other drawback is that it spreads information across a larger number of > directories which tends to make things slower. (Startup is heavily bound by > disk IO / seeks) Agreed. I also maintain that this is not a short term solution and so can be considered as a separate proposal in its own right. > > >>4. Introduce XDG_DATA_INSTALL to indicate where data files should be >>installed and use /usr/share/ otherwise. > > > Just as a user can change where an RPM gets installed or an > autoconf-configured source package. However, it's not within the scope of > this spec to specify what kind of command line options rpm or autoconf (or > custom install scripts) take to specify the install prefix, why should it > specify a way for telling package tools where to install its data files? I'm comfortable with this option. Since there is no existing implementation, and no impetus for anyone to build a system with XDG_DATA_INSTALL, then I see that this will fall back nicely to option #2. Of course, then the next question is - is it just one directory (say /usr/local/share), or a colon separated set of paths? > > >>5. Mandate a lsb-install like tool (desktop-file-install ?) to >>register .desktop files with the menu system without the need to specify >>where they should be installed to (and leaving the actual location where >>they end up implementation specific) > > > Just like #3, the application could install all its files within its own > prefix. The tool could probably symlink the files > into /usr/share/applications with the option to use other locations at the > discretion of the distributor. It doesn't provide a standard way for users to > tell where their data files should be installed to, although an > implementation could chose to follow #4. > > I wanted to say that a drawback is that this tool doesn't exist yet on > current > distributions, but "desktop-file-install" seems available on most distros > already. We're separately working on the xdg-utils package [1], with some hope that they could serve this purpose (at least from a practical stand point, perhaps not from a standard). That's part of my impetus for wanting to button this down. > > Take a deep breath, look at the available options once more and rinse & > repeat > till we find concensus. <grin> Cheers, Jeremy 1. http://webcvs.freedesktop.org/portland/portland/xdg-utils/ description is here: http://webcvs.freedesktop.org/portland/portland/xdg-utils/README?rev=1.1&view=markup _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
