FHS & Qt, KDE, ...

RoryO roryo at roryo.dynup.net
Tue Jul 17 02:31:21 PDT 2001

On Tue, 17 Jul 2001 05:24, you wrote:
> Hello,

>   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 
stuffed.  ;)

> 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 mailing list