Proposal for KDE 4.0

Leo Savernik l.savernik at
Thu Aug 19 11:05:19 BST 2004

Hash: SHA1

Am Donnerstag 19 August 2004 08:44 schrieb Stefan Taferner:
> Am Donnerstag, 19. August 2004 00:07 schrieb Pierre Habouzit:
> > >   KDE is relatively a huge mess compared with traditional UNIX tools,
> > > which /usr was designed for.  It needs to be contained.
> >
> > I disagree, in debian, kde live in /usr, and all works perfectly
> > smooth ...
> >
> > In my school, the machines share their /usr/share on nfs volumes , and we
> > have kde on it. So the sharing problem is not pointless at all

No big deal. If kde is located under /opt/kde, you can share /opt/kde/share.
> The variant I would prefer is:  have the "main" KDE installation sit
> in /usr  (/usr/bin, /usr/lib, /usr/share). This has the benefit that the
> KDE applications just behave like all other applications and users do not
> have to bother.

Users also don't have to bother if kde is installed under /opt/kde<n>. Users 
never have to bother.
> For the case that distributions ship an older KDE version extra (e.g.
> some app that is not ported to KDE4 yet): have the libraries installed
> in /usr/lib/kde3, and all other files of those applications
> in /usr/bin, /usr/share, etc.

How is this supposed to work? Then an old konqueror binary would overwrite the 
current konqueror binary. The only safe way is a prefix of its own.
> I think its quite important to stay uniform with FHS here. 

/opt *is* uniform with FHS (it doesn't state /opt is disallowed, deprecated, 
obsoleted or whatever).

> Otherwise 
> users have to know if an application is KDE or not if they search
> files of that application (.desktop, help files, icons, etc).

Why should they? Either it works (then independent of the prefix), or there's 
a bug somewhere in the application/framework.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


More information about the kde-core-devel mailing list