From: "Malte S. Stretz" <msquadrat.nospamplease@gmx.net>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ?
Date: Mon, 20 Sep 2004 19:19:22 +0200 [thread overview]
Message-ID: <200409201919.23392@malte.stretz.eu.org> (raw)
In-Reply-To: <200409201944.43708.danarmak@gentoo.org>
On Monday 20 September 2004 18:44 CET Dan Armak wrote:
> On Monday 20 September 2004 19:36, Malte S. Stretz wrote:
> > That's actually a good point. Theoretically its possible to share some
> > parts of the system across several machines, which is of course
> > complicated by a /foo/kde/x.y/share directory structure. So most
> > probably your suggestion is the best till now (and also one of the
> > alternatives which was discussed for KDE 4). A directory
> > /usr/bin/kde/x.y feels weird on the first glance, but why not?
>
> I don't understand this point. Could you please elaborate? Why is
> /usr/bin/kde better than either /usr/kde or /usr/packages/kde? Do you
> mean that kde should be split between
> /usr/{bin,lib,share,include,...}/kde/<version> dirs?
Yes. The reason is that this would make KDE follow the rationale behind the
FHS most: Stuff in share can generally be shared (eg. NFS-mounted) across
several machines, while lib continas platform-specific stuff and bin... you
get the point. This might happen rarely but it's the intention behind the
split done in the FHS.
I don't know what you mean with docs which don't belong below lib in your
other mail, was it a misunderstanding of Carsten's mail?
> Specifying such separate dirs rather than a unified KDEDIR/KDEDIRS looks,
> at first sight, to be a major PITA. Maybe they'll improve support for
> this in kde4, but I don't relish the thought of doing it with 3.x. Unless
> there's a way already to specify such separated dirs via env variables a
> la KDEDIRS that I'm not aware of?
I didn't say that this is already possible without much headache, just that
it's maybe the best/cleanest solution for some distant future.
But actually, even currently I don't see a problem with that; the configure
line would become rather long ('./configure --bindir=/usr/bin/kde/3.3
--datadir=/usr/share/kde/3.3 ...') but at least there it would work. And
those dirs are available via eg. 'kde-config --path data' later on.
But I don't know how many stuff inside KDE or how many third-party tools
depend on a "flat" $KDEDIR available via the environment variable(s) so
this might indeed be stuff for KDE 4.
OTOH is it not like the current approach with /usr/kde eats your children or
burns your box. It's just not nice and FHS compliant and stuff but has
been there for quite some time now and could stay as it is for another year
or so until KDE 4 is released. IMHO.
Btw, all this discussion was about KDE, I wonder how GNOME handles this
stuff. Does it also use /usr/gnome/x.y or so something else?
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-09-20 17:19 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-19 19:50 [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? Thomas Weidner
2004-09-19 19:52 ` Ciaran McCreesh
2004-09-19 20:07 ` Mike Frysinger
2004-09-19 20:06 ` Dan Armak
2004-09-19 20:07 ` Joshua J. Berry
2004-09-19 20:13 ` Ciaran McCreesh
2004-09-19 20:16 ` Dan Armak
2004-09-19 20:26 ` Joshua J. Berry
2004-09-19 20:29 ` Ciaran McCreesh
2004-09-19 22:23 ` Joshua J. Berry
2004-09-20 8:41 ` Paul de Vrieze
2004-09-19 20:37 ` Dan Armak
2004-09-19 21:23 ` Malte S. Stretz
2004-09-19 23:38 ` Armando Di Cianno
2004-09-20 8:48 ` Paul de Vrieze
2004-09-20 9:47 ` Malte S. Stretz
2004-09-20 15:56 ` Armando Di Cianno
2004-09-20 19:52 ` Malte S. Stretz
2004-09-20 15:40 ` Dan Armak
2004-09-20 18:30 ` Paul de Vrieze
2004-09-20 19:45 ` Malte S. Stretz
2004-09-19 22:35 ` Joshua J. Berry
2004-09-20 4:10 ` Dan Armak
2004-09-20 4:27 ` Mike Frysinger
2004-09-20 4:47 ` Luke-Jr
2004-09-20 6:09 ` Joshua J. Berry
2004-09-20 9:05 ` Paul de Vrieze
2004-09-20 15:55 ` Sami Samhuri
2004-09-20 16:22 ` Carsten Lohrke
2004-09-20 16:36 ` Malte S. Stretz
2004-09-20 16:44 ` Dan Armak
2004-09-20 17:19 ` Malte S. Stretz [this message]
2004-09-20 17:36 ` Dan Armak
2004-09-20 22:58 ` foser
2004-09-20 17:42 ` Carsten Lohrke
2004-09-20 16:37 ` Dan Armak
2004-09-20 17:35 ` Carsten Lohrke
2004-09-20 18:52 ` Paul de Vrieze
2004-09-20 19:17 ` Carsten Lohrke
2004-09-21 10:47 ` [gentoo-dev] " Duncan
2004-09-21 11:02 ` Duncan
2004-09-21 12:05 ` Carsten Lohrke
2004-09-21 4:58 ` Joel Konkle-Parker
2004-09-21 9:49 ` Paul de Vrieze
2004-09-20 7:49 ` [gentoo-dev] " Simon Watson
2004-09-19 20:09 ` Paul de Vrieze
2004-09-28 2:51 ` [gentoo-dev] " John Croisant
2004-09-28 8:19 ` Paul de Vrieze
2004-09-28 9:24 ` Peter Ruskin
2004-09-28 9:37 ` Paul de Vrieze
2004-09-28 20:32 ` John Croisant
2004-09-29 9:07 ` Paul de Vrieze
2004-09-19 21:55 ` [gentoo-dev] " Luke-Jr
2004-09-19 23:06 ` [gentoo-dev] " Thomas Weidner
2004-09-20 0:03 ` Luke-Jr
2004-09-20 0:55 ` Ciaran McCreesh
2004-09-20 3:50 ` Luke-Jr
2004-09-21 5:10 ` Joel Konkle-Parker
2004-09-21 17:29 ` Helmar Wieland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409201919.23392@malte.stretz.eu.org \
--to=msquadrat.nospamplease@gmx.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox