dobey at ximian.com
Mon May 10 16:11:49 EEST 2004
On Mar , 2004-05-11 at 00:23 +1200, Laszlo Peter wrote:
> On Sat, 2004-05-08 at 03:57, Thomas Leonard wrote:
> > On Fri, May 07, 2004 at 02:39:41PM +0100, Mark McLoughlin wrote:
> > [...]
> > > If you build the entire desktop stack into a different prefix - e.g.
> > > /gnome/head/INSTALL, and you have to set an environment variable to tell
> > > the build where to find some files it has installed, then something is
> > > wrong somewhere.
> > >
> > > I also don't know of anything else that works this way
> > PATH, MANPATH, LD_LIBRARY_PATH, PKG_CONFIG_PATH off the top of my head,
> Not sure about MANPATH, but pkg-config _does_ search
> $libdir/pkgconfig, not /usr/lib/pkgconfig.
> LD_LIBRARY_PATH is evil and is unnecessary if you set the
> runpath correctly at build time. Which basically corresponds
> to what I was asking for: adding the datadir to the default
> search path at build time.
> You don't set LD_LIBRARY_PATH for all users at login just because
> your software something in /opt, do you?
Sometimes. Yes. We have to do this for Evolution on Solaris, because we
are installing it into /opt/gnome, and need to integrate it with the
Gnome install in /usr that Sun provides. The rpath stuff only gets set
properly if the .la files are available for libtool to use, which aren't
needed on linux. Distributions like Red Hat, have started to get rid of
> > for a few environment variables you have to set when installing in /opt.
> > Just set XDG_DATA_DIRS at the same time.
> > > - think of icon themes, for example, the icon theme lookup *will* always
> > > first look in the prefix it was installed in.
> > If you relied upon that, you wouldn't be able to select such themes with
> > ROX-Filer, so your file manager might use a different icon for directories
> > to the rest of your desktop, which would be annoying (though not as
> > serious as using a different MIME database, of course).
> The proposal wasn't to replace /usr/share with $datadir only
> to add it to the search path, preferably to the beginning.
> Packages that install files to the standard locations will still
> work as before.
> If, say, I install my GNOME in /opt/gnome, but your app (rightly)
> only searches /usr/share by default, the worst thing that
> can happen is you still have to set XDG_DATA_DIRS or else
> your app won't find my GNOME build. Why is that any worse
> than where we are now?
Because there is no standard definition of *how* to search the paths in
the XD_DATA_DIRS variable, or the other basedir spec variables. There is
only the suggestion that you should use it. Not everything in Gnome uses
it yet. I don't think there is an xdg basedir implementation in glib
yet. If there is, GtkIconTheme doesn't use it anyway. Just adding
$(datadir) to XDG_DATA_DIRS won't necessarily solve all the potential
problems that can occur right now with using the XDG basedir spec. It
will only solve most cases where everything you are using is in the same
prefix. GtkIconTheme works by virtue of hardcoding $(datadir)
internally, for example. I imagine this is only an issue with mime type
icons on your install or something, rather than a general issue with the
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040510/028c4492/attachment.pgp
More information about the xdg