From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27615 invoked from network); 28 Sep 2004 08:19:39 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 28 Sep 2004 08:19:39 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CCDD0-0004Cd-Pz for arch-gentoo-dev@lists.gentoo.org; Tue, 28 Sep 2004 08:19:38 +0000 Received: (qmail 11834 invoked by uid 89); 28 Sep 2004 08:19:37 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 32435 invoked from network); 28 Sep 2004 08:19:37 +0000 From: Paul de Vrieze To: gentoo-dev@lists.gentoo.org Date: Tue, 28 Sep 2004 10:19:29 +0200 User-Agent: KMail/1.7 References: <200409192306.29528.danarmak@gentoo.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1161027.k4Zvm2K8WC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409281019.35486.pauldv@gentoo.org> Subject: Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? X-Archives-Salt: 3ed514ed-4133-41f9-85aa-ba39b216811f X-Archives-Hash: 9f82ac1eb008a261da732f5b595b8f9d --nextPart1161027.k4Zvm2K8WC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 28 September 2004 04:51, John Croisant wrote: > 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! Too much fun. Have you ever tried to maintain patches on a package with=20 new versions comming out all the time? > > 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? Do you realize that this would amount to serious patches on kde. KDE=20 expects KDEDIR(S) to work the way it does currently. I know it is not=20 ideal, but neither is the FHS. > > 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. You might petition to the qt/kde people, I don't give you much chance, but= =20 the main reason for the current setup is based on the kde/qt setup. Paul =2D-=20 Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net --nextPart1161027.k4Zvm2K8WC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBBWR6XbKx5DBjWFdsRAi/8AJ9wcpgLKc6bk3Uo/7kkPWKdFukKrACeMFJI 3pyCCWxEwnMvd2nPDIhuawI= =D5lu -----END PGP SIGNATURE----- --nextPart1161027.k4Zvm2K8WC--