From: John Croisant <jacius@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ?
Date: Tue, 28 Sep 2004 02:51:01 +0000 (UTC) [thread overview]
Message-ID: <loom.20040928T044859-585@post.gmane.org> (raw)
In-Reply-To: 200409192306.29528.danarmak@gentoo.org
Dan Armak <danarmak <at> gentoo.org> writes:
>
> /usr/qt,kde was my decision at the time. I didn't see any obvious better
> FHS-mandated place to put them in. If there's a better place, I'd at least
> like to hear about it.
I'm a fan of tearing KDE/QT apart and scattering the pieces into their proper,
FHS-friendly places. That is, /usr/kde/share might become /usr/share/kde-X.Y,
and so on. /usr/{kde,qt}/ would be phased out (perhaps keep a directory full of
symlinks to the new places while everything settles). Whether or not this is
feasible, I can't say -- but it sure would be fun for whoever writes the ebuild!
To let multiple versions co-exist, you could use version appending for
directories/libraries (/usr/lib/kde-X.Y) (this is what gnome-2 uses, as foser
pointed out, http://article.gmane.org/gmane.linux.gentoo.devel/21414 ). I don't
see anything in the FHS this goes against (in word or spirit, as I read it), and
a few packages in portage already use this style (not just in /usr/share, but in
/usr/lib, /usr/bin, etc). Taking a peek in /usr/lib, I see Abiword-2.0, gtk-2.0,
the gnome-related libraries, and python having directories using this versioning
system (although python doesn't use the dash). Plus, it seems (to me, at least!)
to make sense: the shared directories are versioned, the library files directly
in /usr/lib are versioned (libfoo.so[.x[.y.z]]), so why not the library
directories in /usr/lib?
The FHS defines the bare minimum (and a few optional) presence of directories,
but beyond that some decision should be made, ideally between distros (and maybe
even between *nixes), as to what hierarchy/naming conventions should be used for
subdirectories.
Hopefully, the new major versions of KDE and QT will make it clearer where they
should go (perhaps by separating the files in a FHS-friendly way). I don't think
that leaving /usr/{kde,qt} in place for the current versions, and "starting
fresh" with the new versions would work, because you'd have to keep the current
versions around anyway (or start up this discussion again) for applications that
don't get updated to the new KDE or QT versions.
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-09-28 3:00 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
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 ` John Croisant [this message]
2004-09-28 8:19 ` [gentoo-dev] " 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=loom.20040928T044859-585@post.gmane.org \
--to=jacius@gmail.com \
--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