[Death to] /opt/gnome
dagmar at speakeasy.net
Tue Oct 15 22:58:27 PDT 2002
On Thu, 10 Oct 2002, Larry Lawrence wrote:
> > You can't really expect a clean slate with _any_ of these packages if the
> > user has been building things in bizarre and unusual ways before you got
> > to 'em.
> We hope they have been good boys and girls and stuck with LFS/BLFS, but if
> not, we try to help them anyway.
I'd be happy if we just didn't see any more of that rare breed who will
state up front that they're following some documentation or other, and
then you find they're running their configure scripts with no arguments
(no --prefix, no nothing) at all.
> > Thankfully it's pretty easy to cajole the build scripts as they
> > stand now (in the past I bitched at plenty of people about it when I'd
> > find one that was broken) into uninstalling packages with a simple `make
> > prefix=/usr/stupid uninstall`.
> So we need to state in the book that the build directories should not be
> deleted until Gnome is up and running?
No-o-o-o-o-o... You've definitely missed my point here. If someone has
installed say, gnome-foo-1.2.3 using --prefix=/opt/doofus, and _didn't_
make an effort to do this in some kind of packagized way, the fastest way
to get that old copy out of there is to simply untar the gnome-foo-1.2.3
tarball, cd into it, run the configure script with the _exact same_
arguments as what they currently have in place, and then just type `make
uninstall`. For nearly all of the packages, that will purge the thing
right out of their system on the first try. Then they can delete that
directory and go on to removing the next one (one MUST do them in reverse
order so one doesn't blow away dependencies the configure scripts will
_still_ expect to see) until they've cleared out all of their installation
from whatever misbegotten --prefix settings they may have used. It should
then be reasonably safe to start over from the top of the Gnome dependency
list using the following _three_ arguments which fairly well ensure FHS
compliance with a minimum of muss and fuss...
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
I think _one_ of my packages may currently be building with /etc/X11 as
the setting for sysconfdir, but I can't be sure of that at the moment.
> > - 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.
> > - libaudiofile and esound should be removed from XII-41 as they are
> > dependencies of Gnome. Considering that very little of section 41
> > appears be significantly dependent on anything else, I think it would
> > probably more useful if most of section 41 were moved into chapter III
> > with the other
> > libraries. Just say so if the BLFS book isn't trying to follow the
> > top-to-bottom approach that the LFS book uses--otherwise I'm probably
> > going to have more things to say along these lines later on about other
> > packages.
> So. BLFS isn't trying a top-to-bottom approach. The locations were laid out
> in a discussion last June and will stay put (you do realize we are trying
> to get 1.0 out). The simple answer is that libaudiofile is also a
> dependency of KDE and esound is a dependency of Enlightenment. It worked
> the same for libxml and libxslt.
I can probably recite the dependency data for my entire filesystem in my
sleep (although I would dearly love to use those braincells for other
> > - The use of varying configuration options throughout the entire Gnome
> > section is a mess.
> You don't appreciate the effort it takes to test when a switch is needed and
> when it is not. :) I think it makes a great point to those paying
> attention, those switches really do things. Consistant switches would also
> go against your feelings on "setting defaults".
Dude, I have been building Gnome 2 from source from top to bottom at
_least_ twice a month for the last six months (and my entire system in
general for a few years now). I know _exactly_ what kind of hell it is to
determine which settings are getting used and which ones aren't because I
use scripts that actually build the things into Slackware format binary
installable packages. In fact, I think you'll find that if you build
things into a DESTDIR location every so often, it becomes really obvious
which things need to be set and which don't. Far easier it is to use
--prefix=/usr --sysconfdir=/etc and --localstatedir=/var. There's about
five or six packages that need something beyond that specified, and a few
of those are optional.
If you'd like to see what I've been doing with Gnome2 lately, feel free to
hop on EfNet and look for my IRC client which sits idle most of the time.
Hit it with a quick /ctcp Dagmar XDCC LIST and then maybe an XDCC SEND #1
to get the tarball which is veritably _bursting_ with build scripts which
flat out make Slackware packages from whole cloth. If you like, edit the
finalizepackage() subroutine in functions.sh and change it to a quick cp
-adR and exit to keep it from trying to invoke the Slackware package tools
if you don't have them around someplace. There's nothing much in there to
automate series of packages builds, and some parts of it are more polished
than others, but on the whole those things can properly build both gnome
1.4.x and gnome 2.0.x. (0.0.3 release is VERY overdue, I was busy
breaking a new mainboard in this weekend)
...and consistent switches do not go against my arguments about setting
unnecessary defaults. The three basic arguments to ./configure I've been
using _can't_ be wrong when a package's makefiles are constructed
correctly. In any case what I was referring to is that /opt/gnome and
/opt/gnome2 are being used without respect to which tree the package is
> > Gnome-libs in particular makes my hair stand on end.
> I'll agree with this, but probably not for the same reason. Gnome-libs
> should use the /opt/gnome/var directory like the rest of gnome-1.4.
Actually not. The use of /opt/gnome/var would be quite contrary to the
FHS. For all intents and purposes, /opt is supposed to be a static
filesystem. Anything that goes into /opt/gnome/var is only supposed to be
there for long enough for it to be copied into /var/opt/<packagename>,
because "var" is for variable data.
> > - Verily, I doth submit that the use of yon 'whilst' is summat foolish.
> > ;)
> That why I'm only the assistant editor.
> I'll try to get to the other comments soon. I do hope others chime in.
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