--Boundary-02=_zdvZ/lGpam9PYoN
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 15 September 2003 22:56, George Staikos wrote:
>    Does anyone have a suggestion for kdedirs design to avoid the following
> problem?
>
>   - User installs KDE in /usr
>   - User installs ksomeapp in /usr
>   - User installs new version of ksomeapp from source in /usr/local and
> forgets about the one in /usr
>   - User wonders why features are missing from the application and plugins
> don't work
>
>    The problem is that KDE picks up the files in /usr first.  Can we
> reliably detect this situation and warn/error out if the app is installed
> twice?  Can we make the bin path correlate with the "primary" source for
> data (.rc files, etc)?  Another suggestion?

Ok, the problem is not so simple really.
To solve this problem, we need attack applications as well.
Today we can't identify version/release from applications. There aren't any=
=20
identification that the /usr app is older than /usr/local.
If we have an basic info, like version with release date ( developer could =
be=20
released same app version with lot of bug fixes, so date makes sense ), and=
=20
so doesn't matter how many apps you identify in kdedirs. This can be very=20
usefull even for test, if we add a configuration dialog, that can choose wi=
ch=20
one must read or not, and even for KIOSK, preventing user to see and use su=
ch=20
application.
=46or a new installed app, system can warn user about two or more versions =
of=20
this application are in the system and choose wich one must use.

But, as i said in the beginning:
=2D Apps need have a proper unique id ( like kdebeuf space )
=2D There must be a way to recover their version-date or whatever time base=
d id=20
to identify which is he new one or not.

If we can find an easy way to do this, like change all apps automatically, =
all=20
the work will be under kdedirs handling and add this new features..
This will enable user have how many application version installed on system=
 he=20
choose.

But ( always have a but ), there some problems associated:
=2D Overhead to tell the system every time you run the application the new =
dir=20
base of it, and of course, avoid as an example,  that this application load=
s=20
the correct part needed, like a khtml part, because you can have a khtml pa=
rt=20
on many dirs, and app don't really know abou this, just kdedirs management.
=2D Old applications come fomr pre 3.2 release will not embrace this featur=
e,=20
and can cause some problems, if we decide that need use this ones. This can=
=20
be easily solved as decidind that just apps >=3D 3.2 kde release will be=20
accepted.
=2D User confusion - Regular users will be very confused about this behavio=
ur,=20
and maybe can't easily understand that the old application, which can have=
=20
many of personal data already, must be disabled and suddenly lost your=20
personal data, since new app is installed on new dir. This CAN happen today=
=20
because not all apps are handling the right rc update, and sometime there=20
aren't a better way to fix it than remove rc file.

Ok, to start, this is my 2c.

=2D-=20
Helio Castro
KDE Developer
Development Conectiva S.A.

--Boundary-02=_zdvZ/lGpam9PYoN
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/Zvdz8KVbYLGVrvcRAjdgAKDFMBlo2pOxR6CRvLCnu1N3pSNGQQCfZ+P0
/VzYz/BXofEkJuscfe7L3j8=
=kY62
-----END PGP SIGNATURE-----

--Boundary-02=_zdvZ/lGpam9PYoN--