FHS & Qt, KDE, ...
roryo at roryo.dynup.net
Tue Jul 17 02:31:21 PDT 2001
On Tue, 17 Jul 2001 05:24, you wrote:
> I see that e.g. Qt is suggested to install to /usr/local/qt, KDE to
> /usr/local/kde. I think more programs also violate the FHS standard.
Yeah i know what u mean... I use /opt/KDE and /opt/GNOME for my
GNOME and KDE stuff... For gnome this requires a little hacking, but
more about that in a bit... ;)
> Well, I don't care much about the standard, but this makes my
> dirtree ugly... I think /usr/local is such a place where you could
> install something, then just rm -rf /usr/local, rebuild the tree and
> behave as nothing has been installed ;)
Well i must admit i use ~/ for testing or /tmp, but then my ~ is set up
as a fully working enviroment withing itself, most of the time i'm in a
chroot when in ~, but thats just me being paranoid...
> So, if I want to put things in their place, where should qt,kde and
> such go?.. Right now on my temporary system I've installed Qt to
> /usr/lib/qt (a symlink to /usr/lib/qt-?.??) and kde is installed in
Okay me thoughts.... QT / gtk-glib belong in /usr/X11R6/[bin/include/lib]
as they are used exclusivly in X and are shared between more than a
couple if apps...
> (ouch!) /usr/X11R6/kde ;)) Heh this KDE thing really doesn't look
> good, it's just that I've no idea where to put it. I'd like to hear
> your opinions about such positions. Maybe you should adjust the
> hints? IIRC the "db" package also has this problem...
Haven't seen a hint about db, but for a good FHS install of db have a
look at the sendmail hint. JJones did it right...
> Oh BTW the KDE hint is a a bit outdated I think (sorry if that's
> because I was using an older version).
> P.S. Is anybody having problems with "db 1.85 incompatibilities" while
> compiling gnome-utils? My db version is 3.x.x (sorry can't remember
Ah! Gnome is mainly writen by RedHat - RedHat users etc... they can therefore
use a simple dbopen in the configfile, however for the rest of us will need
to hack the ./configure as follows... sed or do by hand...
dbopen() becomes __db_dbopen()
now the source files use db properly, it's just the configure that is
> exactly, maybe this number is totally wrong ;(.
> Maybe someone could help me on this?
Unsubscribe: send email to lfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the lfs-dev