From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9071 invoked from network); 20 Sep 2004 09:47:23 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 20 Sep 2004 09:47:23 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1C9KlW-0001mn-VU for arch-gentoo-dev@lists.gentoo.org; Mon, 20 Sep 2004 09:47:23 +0000 Received: (qmail 23236 invoked by uid 89); 20 Sep 2004 09:47:22 +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 30746 invoked from network); 20 Sep 2004 09:47:22 +0000 X-Authenticated: #12263026 From: "Malte S. Stretz" Organization: To: gentoo-dev@lists.gentoo.org Date: Mon, 20 Sep 2004 11:47:18 +0200 User-Agent: KMail/1.7 References: <200409192323.23736@malte.stretz.eu.org> <200409201048.59958.pauldv@gentoo.org> In-Reply-To: <200409201048.59958.pauldv@gentoo.org> X-Archive: encrypt X-Face: $(^e[V4D-[`f2EmMGz@fgWK!e.B~2g.{08lKPU(nc1J~z\4B>*JEVq:E]7G-\6$Ycr4<;Z!|VY6Grt]+RsS$IMV)f>2)M="tY:ZPcU;&%it2D81X^kNya0=L]"vZmLP+UmKhgq+u*\.dJ8G!N&=EvlD X-Spam-Checker: SpamAssassin X-Accept-Language: de, en MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409201147.18918@malte.stretz.eu.org> Subject: Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? X-Archives-Salt: 4543f67d-aa12-4626-a7d1-4b1666720b86 X-Archives-Hash: 87bf6bf38271e73e4f667b19c0e817ff On Monday 20 September 2004 10:48 CET Paul de Vrieze wrote: > On Sunday 19 September 2004 23:23, Malte S. Stretz wrote: > >[...] > > If something is broken, it's normally the better to fix it instead of > > working around. So maybe the FHS should be refined to support what is > > needed by either adding an additional subdirectory below /usr or a > > completely new root-level directory. I mean it's not like the place in > > / is limited by anything and /svc was also added lately (and btw Linux' > > /sys is completely against the FHS). > > Welcome to the real world. This is broken for a long long time and I'm > sure that it was mentioned to the FHS people a long time ago. Yes, I know. But I don't understand why it isn't fixed then. Ok, I already had some lengthy discussions with Daniel Quinlan about stuff like this (the other guys I don't know) but in the end we always^Wmostly managed to come to a sensible solution. What I don't get is that the FHS is clearly flawed (if not by design then at least the wording could be clearer) and that is known for years. So people had quite some time to find the problems with the current version but instead of gathering and working on a fixed version everybody mumbles "bah, FHS sucks, we do it how we interpret it" and goes on. For the last few years I read threads like this one at least twice per year on various mailinglists or websites. I don't propose to create something completely new like, say, what Apple uses in MacOS X, just to refine the current state of art. As I said, it's not like we lack space in / or need to look like a "real" SysV system. Linux (or GNU/Linux if you prefer that) is IMO about invention, so why do we try to cram everything into the olde Unix directory structure while it obviously doesn't fit? > > Another thing which cropped up in combination with the macchanger > > ebuild (the issue is in b.g.o) was that sometimes shomething like > > /share or /lib/share is needed. > > > > The current FHS mailinglist is more a spamtrap than anything. Maybe a > > new one should be created. There a group of people consisting of (a) > > the previous FHS contributors (b) somebody from each big distro and (c) > > some people from the bigger desktop environments (or freedesktop.org) > > can get together and try to fix all the current issues with the FHS and > > create a version 3.0. > > When the FHS gets sensible enough to offer a solution for existing > problems then I'm surely in favour of following it, but as it stands the > FHS does not answer some of the questions we have. My point is that the FHS won't get any better if people don't get together and fix it. Of course can we continue to curse the FHS 2.x for the next ten years but how productive is that? > ps. The other "solution" could be to do it like the eclipse ebuild does > and install in /usr/lib/eclipse or /usr/lib/kde/3.3, although I even like > it less. That's actually what KDE is aiming for for version 4 (and AFAIK what GNOME already uses). And apart from that, Qt most probably belongs to /usr/lib/qt. > I think that our solution is best. To be FHS compliant (better, > to sidestep the FHS) we could make a new subdir to /usr where we put > these packages. This does not violate the FHS as no package is directly > under /usr and we still follow our own guidelines, and provide a clean > solution. Cheers, Malte -- [SGT] Simon G. Tatham: "How to Report Bugs Effectively" [ESR] Eric S. Raymond: "How To Ask Questions The Smart Way" -- gentoo-dev@gentoo.org mailing list