[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    User installed apps, Was: kded excluding dirs?
From:       weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-12-02 11:09:46
[Download RAW message or body]

Hi,

lets try again:

At university our students can not install apps since they are not
root. So they can install only in their home directories.
People reported to me that they can not install the RPM
packages in their home dirs. Is there any way?

And further more: Can we set LD_LIBRARY_PATH to contain
$HOME/.kde/libs ? Distributors should in addition
add $HOME/.kde/bin to $PATH, or we do that in startkde.

And (related to ksycoca) if two services of the same name and the
same servicetype exists. One of the user and one in the global
environment. In this case it would IMHO be a good idea to perfer
the service the user has installed himself. How does KSyCoCa handle
this ?

Bye
Torben


On Thu, 2 Dec 1999, David Faure wrote:

> 
> > Hi,
> >
> > On Thu, 2 Dec 1999, David Faure wrote:
> >
> > > > On Sun, Nov 28, 1999 at 01:57:04PM +0000, David Faure wrote:
> > > >
> > > > Hi,
> > > >
> > > > > > is it possible to configure kded which directories to watch for
> new
> > > > > > mimetypes, .desktop-files, et al?
> > > > > > I imagine our university network, where the KDE-installation is
> quite
> > > > > > static (you wouldn't need to run kded at all), but with KDEDIRS, a
> user
> > > > > > could install his own additions, where kded would make sense.
> > > > > > So could I tell kded to watch e.g. ~/kde, but not /usr/KDE?
> > > > > If you do that you need a full copy of the
> mimetype+apps+services+servicetypes
> > > > stuff in ~/.kde, otherwise it won't work...
> > > >
> > > > ideally, kded shouldn't need to recreate the entire ksyscoca-file, but
> > > > instead only update/remove/add changed items.
> > > > But I guess you would have implemented that already, if it
> > > > would be easily possible. Otherwise, one could tell kded to not use
> KDirWatch on the
> > > > global stuff, but to restrict it to local files. If something changes,
> > > > well, recreate the entire ksycoca, but at least don't monitor
> > > > it all the time.
> > >
> > > No, that's not how kded/ksycoca has been designed.
> > > (If you want to do add/update/... you either need to keep things in
> kded's
> > > memory,
> > > which we don't want, and you can't just append something to the file
> since
> > > all indexes have to be updated).
> > >
> > > I think the best solution is to have an option "only scan user's dirs"
> > > that does what it says : only adds user's dirs to KDirWatch, not global
> > > dirs, but when the ksycoca file is recreated, it will recreate the whole
> file,
> > > reading the files on the global dir as well.
> > >
> > > The only case where this breaks is if admins decide to change a global
> file,
> > > but that's where the compromise is.
> > >
> > > OTOH since kded runs on startup, every one will get the new settings
> > > on the next logon.
> >
> > IMHO that is a cool optimization. It will work quite well in large
> > environments with sysadmins (like university) while the current
> > method is better for peoples home workstation where they install
> > new software every second day in the global environment.
> Yup.
> 
> > There comes a question to my mind: Did anybody test or at least
> > think about installing new apps (including binary and libs)
> > in a users home directory?
> I don't understand this ?!
> It has no relation with ksycoca - which only deals with .desktop files.
> And if somebody installs ~/bin/konsole, then this will be the one started by
> even the global konsole.desktop, as long as ~/bin is before in $PATH...
> 
> This works because there is no absolute path to binaries anywhere.
> 
> 
> --
> David Faure
> faure@kde.org - KDE developer
> david@mandrakesoft.com - Mandrake
> david.faure@cramersystems.com - Cramer Systems
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]