[Death to] /opt/gnome

Dagmar d'Surreal dagmar at speakeasy.net
Tue Oct 15 22:55:40 PDT 2002


On Sat, 12 Oct 2002, Larry Lawrence wrote:

> Larry Lawrence wrote:
>
> >>  - I'd really like someone to point out where in the Developer's guides
> >>   for either Gnome 1.4.x or Gnome 2.0.x the variable GNOME_LIBCONFIG is
> >>   cited.  I have never seen this sucker mentioned anywhere before.  The
> >>   fact that it's set to /usr/lib makes me suspect it's yet another case
> >>   of specifying defaults unnecessarily (which is bad--I'll 'splain
> >>   later).
> >
> > I didn't make it up, so I'll find my source.
> >
>
> > Larry
>
> GNOME_LIBCONFIG is a Gnome-1.4 variable.  Its purpose is to point to
> alternative pkgconfig paths.  The default pkgconfig is based on gnomes
> prefix, which in our case is /opt/gnome/lib, so we are not specifying the
> default.

Okay, so basically this variable has to be set _because_ the rest of the
lot is being put into /opt.  Another point against using /opt in my eyes.

You've been saying an awful lot along the lines of broken installs
buggering up the system, but I'd like to point out that --prefix=/usr
doesn't fall prey to this.  If the user's previous install happened to be
in /usr/local they can always just _torch_ that and not worry about the
consquences if they don't feel like undoing the mess on their own...
but... since /usr/local/ is also in the search paths, if the dependency
lists are followed properly in order, there's nothing to stop someone
frome doing a (pardon the complex line that follows)

./configure --prefix=/usr/local && make && make uninstall && make \
distclean && ./configure --prefix=/usr --sysconfdir=/etc \
--localstatedir=/var && make && make install && ldconfig

  ...in each package and it _should_ normally be safe unless something is
completely and totally buggered up.  (the complete uninstallation in
reverse order mentioned earlier would only be needed for severe cases).

Even if the user didn't specify sysconfdir and localstatedir before, a
rebuild of everything--specifying them this time--cuts right through the
problem (well, provided one is not running Gnome at the time... GConf
doesn't much care for having the entire schema hierarchy moved while it's
running).  I speak from experience on this one.


-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-dev' in the subject header of the message



More information about the blfs-dev mailing list