1 |
On Monday 20 September 2004 20:19, Malte S. Stretz wrote: |
2 |
> Yes. The reason is that this would make KDE follow the rationale behind |
3 |
> the FHS most: Stuff in share can generally be shared (eg. NFS-mounted) |
4 |
> across several machines, while lib continas platform-specific stuff and |
5 |
> bin... you get the point. This might happen rarely but it's the intention |
6 |
> behind the split done in the FHS. |
7 |
I see. |
8 |
|
9 |
> |
10 |
> I don't know what you mean with docs which don't belong below lib in your |
11 |
> other mail, was it a misunderstanding of Carsten's mail? |
12 |
My point was that since lib is meant for, well, libraries (and occasional |
13 |
binaries), it'd be inappropriate to put things like docs under it. Just |
14 |
inelegant, and people wouldn't expect it. Especially in view of the |
15 |
filesystem sharing scenario you outlined. |
16 |
|
17 |
> |
18 |
> > Specifying such separate dirs rather than a unified KDEDIR/KDEDIRS looks, |
19 |
> > at first sight, to be a major PITA. Maybe they'll improve support for |
20 |
> > this in kde4, but I don't relish the thought of doing it with 3.x. Unless |
21 |
> > there's a way already to specify such separated dirs via env variables a |
22 |
> > la KDEDIRS that I'm not aware of? |
23 |
> |
24 |
> I didn't say that this is already possible without much headache, just that |
25 |
> it's maybe the best/cleanest solution for some distant future. |
26 |
Definitely - if KDE makes it as easy as KDEDIRS, I'd vote for such a solution |
27 |
too in the longterm. |
28 |
|
29 |
> |
30 |
> But actually, even currently I don't see a problem with that; the configure |
31 |
> line would become rather long ('./configure --bindir=/usr/bin/kde/3.3 |
32 |
> --datadir=/usr/share/kde/3.3 ...') but at least there it would work. And |
33 |
> those dirs are available via eg. 'kde-config --path data' later on. |
34 |
> |
35 |
> But I don't know how many stuff inside KDE or how many third-party tools |
36 |
> depend on a "flat" $KDEDIR available via the environment variable(s) so |
37 |
> this might indeed be stuff for KDE 4. |
38 |
Seems like it to me, too. |
39 |
|
40 |
> |
41 |
> OTOH is it not like the current approach with /usr/kde eats your children |
42 |
> or burns your box. It's just not nice and FHS compliant and stuff but has |
43 |
> been there for quite some time now and could stay as it is for another year |
44 |
> or so until KDE 4 is released. IMHO. |
45 |
Agreed. |
46 |
|
47 |
> Btw, all this discussion was about KDE, I wonder how GNOME handles this |
48 |
> stuff. Does it also use /usr/gnome/x.y or so something else? |
49 |
No idea. I seem to remember gnome 1.4 and 2.0 coexisted back in the day, but |
50 |
don't remember how... Any gnome devs reading this thread? ;-) |
51 |
|
52 |
-- |
53 |
Dan Armak |
54 |
Gentoo Linux developer (KDE) |
55 |
Matan, Israel |
56 |
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key |
57 |
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 |