* [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? @ 2004-09-19 19:50 Thomas Weidner 2004-09-19 19:52 ` Ciaran McCreesh ` (2 more replies) 0 siblings, 3 replies; 59+ messages in thread From: Thomas Weidner @ 2004-09-19 19:50 UTC (permalink / raw To: gentoo-dev Hi, I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's there in order to make it possible to have several versions of kde/qt installed side by side. If there was a way to make qt and kde installations FHS compilant without removing the possibility to have several versions installed side by side,whould there be any interest to add it to portage or want gentoo developers to stick with the current solution? I know the current version works, but it conflicts with the FHS (and therefore with the LSB). Thomas Weidner -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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 21:55 ` [gentoo-dev] " Luke-Jr 2 siblings, 1 reply; 59+ messages in thread From: Ciaran McCreesh @ 2004-09-19 19:52 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 431 bytes --] On Sun, 19 Sep 2004 21:50:46 +0200 Thomas Weidner <3.14159@gmx.net> wrote: | I know the current version works, but it conflicts | with the FHS (and therefore with the LSB). LSB compliance isn't exactly high on our list of priorities... FHS, maybe, but definitely not LSB. -- Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 19:52 ` Ciaran McCreesh @ 2004-09-19 20:07 ` Mike Frysinger 0 siblings, 0 replies; 59+ messages in thread From: Mike Frysinger @ 2004-09-19 20:07 UTC (permalink / raw To: gentoo-dev On Sunday 19 September 2004 03:52 pm, Ciaran McCreesh wrote: > LSB compliance isn't exactly high on our list of priorities... FHS, > maybe, but definitely not LSB. LSB is much more than a filesystem spec which is why we dont bend over backwards for it, but FHS is something we try for and yes, the way we install KDE/QT fly in the face of FHS ... but it does allow us to easily SLOT kde versions ... -mike -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:06 ` Dan Armak 2004-09-19 20:07 ` Joshua J. Berry ` (2 more replies) 2004-09-19 21:55 ` [gentoo-dev] " Luke-Jr 2 siblings, 3 replies; 59+ messages in thread From: Dan Armak @ 2004-09-19 20:06 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1211 bytes --] On Sunday 19 September 2004 22:50, Thomas Weidner wrote: > Hi, > > I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's > there in order to make it possible to have several versions of kde/qt > installed side by side. If there was a way to make qt and kde > installations FHS compilant without removing the possibility to have > several versions installed side by side,whould there be any interest to > add it to portage or want gentoo developers to stick with the current > solution? I know the current version works, but it conflicts with the > FHS (and therefore with the LSB). /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. If it's a matter of simply moving the /usr/{qt,kde}/$VERSION directories anywhere else, that's as simple as setting a few env variables before an emerge, and changing their default vaules in eclasses or whereever. -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:09 ` Paul de Vrieze 2004-09-28 2:51 ` [gentoo-dev] " John Croisant 2 siblings, 2 replies; 59+ messages in thread From: Joshua J. Berry @ 2004-09-19 20:07 UTC (permalink / raw To: Dan Armak; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 491 bytes --] On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote: > > /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. Why /usr instead of /opt? Based on my recollection of the FHS, it seems like /opt would be the better place to put it ... -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:07 ` Joshua J. Berry @ 2004-09-19 20:13 ` Ciaran McCreesh 2004-09-19 20:16 ` Dan Armak 1 sibling, 0 replies; 59+ messages in thread From: Ciaran McCreesh @ 2004-09-19 20:13 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 592 bytes --] On Sun, 19 Sep 2004 13:07:37 -0700 "Joshua J. Berry" <condordes@gentoo.org> wrote: | On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote: | > | > /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. | | Why /usr instead of /opt? Because /opt is evil, especially for things we're building ourselves. -- Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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-20 7:49 ` [gentoo-dev] " Simon Watson 1 sibling, 2 replies; 59+ messages in thread From: Dan Armak @ 2004-09-19 20:16 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1326 bytes --] On Sunday 19 September 2004 23:07, Joshua J. Berry wrote: > On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote: > > /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. > > Why /usr instead of /opt? Quoting FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.html): "Purpose: /opt is reserved for the installation of add-on application software packages." To this day I haven't heard a good definitin of "add-on" software in this context. I don't see qt/kde as being an addon to anything else. Moreover, as Paul points out, in Gentoo we only use /opt so far for binary-only packages and for packages that don't obey the general unix directory structur (/bin, /lib, /share, /include...). qt/kde has neither of these characteristics. The FHS says about /usr: "Large software packages must not use a direct subdirectory under the /usr hierarchy." I agree this rules out what we're doing. The problem is, noone ever proposed a better (more FHS-compliant) solution. -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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 20:37 ` Dan Armak 2004-09-20 7:49 ` [gentoo-dev] " Simon Watson 1 sibling, 2 replies; 59+ messages in thread From: Joshua J. Berry @ 2004-09-19 20:26 UTC (permalink / raw To: Dan Armak; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1924 bytes --] On Sun, Sep 19, 2004 at 11:16:44PM +0300, Dan Armak wrote: > On Sunday 19 September 2004 23:07, Joshua J. Berry wrote: > > On Sun, Sep 19, 2004 at 11:06:29PM +0300, Dan Armak wrote: > > > /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. > > > > Why /usr instead of /opt? > Quoting FHS 2.3 (http://www.pathname.com/fhs/pub/fhs-2.3.html): > "Purpose: /opt is reserved for the installation of add-on application software > packages." > > To this day I haven't heard a good definitin of "add-on" software in this > context. I don't see qt/kde as being an addon to anything else. I could easily see KDE/Qt being treated as an "add-on", given that (a) they're not necessary for core system functionality (whatever that means), and (b) they are both heavily-bloated, and you probably don't want to pollute /usr... > Moreover, as Paul points out, in Gentoo we only use /opt so far for > binary-only packages and for packages that don't obey the general unix > directory structur (/bin, /lib, /share, /include...). qt/kde has neither of > these characteristics. This is true, but I'm wondering if that's maybe a silly move on our part, for just this reason. > The FHS says about /usr: "Large software packages must not use a direct > subdirectory under the /usr hierarchy." I agree this rules out what we're > doing. The problem is, noone ever proposed a better (more FHS-compliant) > solution. I really do think this is what /opt was intended for. "Add-on" sounds to me like it's one of those purposefully open-ended words that you can interpret however you like. Actually, the whole section on /opt in the FHS reads that way ... -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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-19 20:37 ` Dan Armak 1 sibling, 1 reply; 59+ messages in thread From: Ciaran McCreesh @ 2004-09-19 20:29 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1240 bytes --] On Sun, 19 Sep 2004 13:26:01 -0700 "Joshua J. Berry" <condordes@gentoo.org> wrote: | > To this day I haven't heard a good definitin of "add-on" software in | > this context. I don't see qt/kde as being an addon to anything else. | | I could easily see KDE/Qt being treated as an "add-on", given that (a) | they're not necessary for core system functionality (whatever that | means), and (b) they are both heavily-bloated, and you probably don't | want to pollute /usr... They're installed by the package manager. They are therefore not add-on. | I really do think this is what /opt was intended for. "Add-on" sounds | to me like it's one of those purposefully open-ended words that you | can interpret however you like. Actually, the whole section on /opt | in the FHS reads that way... No, /opt was intended as a temporary place for Sun to stick things until they decided where in /usr they should go. Unfortunately, someone messed up and /opt became widely used. The conventional non-screwed-up place is /usr/kde/whatever, but FHS doesn't like this for some bizarre reason. -- Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:29 ` Ciaran McCreesh @ 2004-09-19 22:23 ` Joshua J. Berry 2004-09-20 8:41 ` Paul de Vrieze 0 siblings, 1 reply; 59+ messages in thread From: Joshua J. Berry @ 2004-09-19 22:23 UTC (permalink / raw To: Ciaran McCreesh; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1227 bytes --] On Sun, Sep 19, 2004 at 09:29:40PM +0100, Ciaran McCreesh wrote: > On Sun, 19 Sep 2004 13:26:01 -0700 "Joshua J. Berry" > <condordes@gentoo.org> wrote: > | > To this day I haven't heard a good definitin of "add-on" software in > | > this context. I don't see qt/kde as being an addon to anything else. > | > | I could easily see KDE/Qt being treated as an "add-on", given that (a) > | they're not necessary for core system functionality (whatever that > | means), and (b) they are both heavily-bloated, and you probably don't > | want to pollute /usr... > > They're installed by the package manager. They are therefore not add-on. No, that's not the way the FHS interprets "add-on". "Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator." By your logic, Gentoo has no business sticking *anything* in /opt. I don't think packages in /opt (acroread, sun-jdk, openoffice, et al) violate the FHS, and if they don't, then I don't see why KDE/Qt in /opt would. -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 22:23 ` Joshua J. Berry @ 2004-09-20 8:41 ` Paul de Vrieze 0 siblings, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-20 8:41 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 905 bytes --] On Monday 20 September 2004 00:23, Joshua J. Berry wrote: > > No, that's not the way the FHS interprets "add-on". > > "Distributions may install software in /opt, but must not modify or > delete software installed by the local system administrator without the > assent of the local system administrator." > > By your logic, Gentoo has no business sticking *anything* in /opt. > > I don't think packages in /opt (acroread, sun-jdk, openoffice, et al) > violate the FHS, and if they don't, then I don't see why KDE/Qt in /opt > would. The big difference is there are many packages that actively depend on kde. While all those other packages can be seen as "self-contained". They are leaf nodes in the dependency tree. Kde certainly isn't (well, kdelibs and kdebase at least). Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:26 ` Joshua J. Berry 2004-09-19 20:29 ` Ciaran McCreesh @ 2004-09-19 20:37 ` Dan Armak 2004-09-19 21:23 ` Malte S. Stretz 2004-09-19 22:35 ` Joshua J. Berry 1 sibling, 2 replies; 59+ messages in thread From: Dan Armak @ 2004-09-19 20:37 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2197 bytes --] On Sunday 19 September 2004 23:26, Joshua J. Berry wrote: > I could easily see KDE/Qt being treated as an "add-on", given that (a) > they're not necessary for core system functionality (whatever that means), Er, so does that mean anything not in the system profile should go in /opt? I'd say qt/kde is as important a piece of a dekstop system using it as any other. > and (b) they are both heavily-bloated, Bloated in what respect? Size, speed? And what does it have to do with where we install them to? > and you probably don't want to > pollute /usr... It's true that I don't want to, only I don't see a better solution. If there's a general consensus on moving to /opt I can live with that, because it doesn't affect the ebuilds/eclasses/results one bit. It's just that it's entirely inconsistent with the way we're using /opt right now. And what if, in a year from now, twenty other projects will decide it's good for the users to allow many versions to be installed side by side? Will we move everything to /opt? My point here is that kde itself is not special in any way (although qt arguably is, since you do want different qt2 and qt3 programs side by side, but then the qt libraries could live together in /usr with some effort). It's just that kde users asked for this functionality a lot, so I added it. Apart from running two stable trees, kde developers use this to run a stable tree and cvs HEAD. <snip> > I really do think this is what /opt was intended for. "Add-on" sounds to > me like it's one of those purposefully open-ended words that you can > interpret however you like. Actually, the whole section on /opt in the FHS > reads that way ... Well, I simply don't know what they mean by add-on, so obviously you can interpret it however you like :-) However, isn't there -any- consensus on what this is supposed to mean? Can we just ask the FHS guys if this is so unclear? (And cf. what Ciaran just replied.) -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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-19 22:35 ` Joshua J. Berry 1 sibling, 2 replies; 59+ messages in thread From: Malte S. Stretz @ 2004-09-19 21:23 UTC (permalink / raw To: gentoo-dev On Sunday 19 September 2004 22:37 CET Dan Armak wrote: > On Sunday 19 September 2004 23:26, Joshua J. Berry wrote: > >[...] > > I really do think this is what /opt was intended for. "Add-on" sounds > > to me like it's one of those purposefully open-ended words that you can > > interpret however you like. Actually, the whole section on /opt in the > > FHS reads that way ... > > Well, I simply don't know what they mean by add-on, so obviously you can > interpret it however you like :-) > > However, isn't there -any- consensus on what this is supposed to mean? > Can we just ask the FHS guys if this is so unclear? (And cf. what Ciaran > just replied.) I'll ask Daniel Quinlan what he things when pops online. But currently each distro does it how the maintainer like it (or interprets the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat something else, and I think Debian throws all the stuff into /usr. To me this sounds like the FHS is flawed if it comes to stuff like this. Even the /usr/X11R6 directory is only there because it was always there though an alternative is missing, too. Ironically was there lately a discussion on the KDE core-devel list if the default location for KDE should be /opt/kde for KDE 4 (instead of /usr/local). 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). 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. 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 21:23 ` Malte S. Stretz @ 2004-09-19 23:38 ` Armando Di Cianno 2004-09-20 8:48 ` Paul de Vrieze 1 sibling, 0 replies; 59+ messages in thread From: Armando Di Cianno @ 2004-09-19 23:38 UTC (permalink / raw To: gentoo-dev Some questions, and my $0.02 ... >>> I really do think this is what /opt was intended for. "Add-on" >>> sounds >>> to me like it's one of those purposefully open-ended words that you >>> can >>> interpret however you like. Actually, the whole section on /opt in >>> the >>> FHS reads that way ... ... > But currently each distro does it how the maintainer like it (or > interprets > the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat something > else, and I > think Debian throws all the stuff into /usr. To me this sounds like > the FHS > is flawed if it comes to stuff like this. Even the /usr/X11R6 > directory is > only there because it was always there though an alternative is > missing, too. So, I'm taking care of bringing a usable GNUstep system into portage. (Anyone following this: I'm pretty much waiting for another stable release of -gui, as to not litter portage with cvs-pull-and-tar ebuilds, before uploading anything...). GNUstep has classically been installed into /usr/GNUstep, which would obviously violate the FHS. The thing is, imho, the FHS is for UNIX/UNIX-like systems, while GNUstep just-so-happens to be a system that can run on top of UNIX/UNIX-like systems (as well as Windows, OS X, etc). All that is required is a "root" to place it's base, and any other run-time created files can be bridged into the FHS as appropriate. The problem is, that quite like X11, the hierarchy under .../GNUstep is different from the rest of the FHS recommended directories, reflecting the fact that GNUstep is not UNIX. I'd happily use /opt, but that seems rather non-Gentoo, atm. I'll be following this thread, and will likely follow recommendations, as applicable, that are made for qt or kde. Keep in mind that GNUstep is "a whole other system" and not just a "set of libraries and programs". Any specific recommendations about what I should do concerning GNUstep would also be greatly appreciated. Thanks for keeping this in mind, __armando -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:40 ` Dan Armak 1 sibling, 2 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-20 8:48 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2517 bytes --] On Sunday 19 September 2004 23:23, Malte S. Stretz wrote: > But currently each distro does it how the maintainer like it (or > interprets the FHS) -- Gentoo uses /usr/kde, SuSE /opt/kde, RedHat > something else, and I think Debian throws all the stuff into /usr. To > me this sounds like the FHS is flawed if it comes to stuff like this. > Even the /usr/X11R6 directory is only there because it was always there > though an alternative is missing, too. > > Ironically was there lately a discussion on the KDE core-devel list if > the default location for KDE should be /opt/kde for KDE 4 (instead of > /usr/local). > > 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. > > 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. Paul 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. 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. -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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 15:40 ` Dan Armak 1 sibling, 1 reply; 59+ messages in thread From: Malte S. Stretz @ 2004-09-20 9:47 UTC (permalink / raw To: gentoo-dev 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" <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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 9:47 ` Malte S. Stretz @ 2004-09-20 15:56 ` Armando Di Cianno 2004-09-20 19:52 ` Malte S. Stretz 0 siblings, 1 reply; 59+ messages in thread From: Armando Di Cianno @ 2004-09-20 15:56 UTC (permalink / raw To: gentoo-dev On 2004-09-20 05:47:18 -0400 Malte S. Stretz <msquadrat.nospamplease@gmx.net> wrote: > 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? Just to be ontologically aligned with those that created the NeXTStep hierarchy, OS X (NeXTStep/OpenStep's logical descendants [alongside GNUstep]) has it's own UNIX-y/FHS-y hierarchy, from the BSD tools, _and_ a NeXT-y hierarchy. I chimed in before about what I should do with GNUstep, but whereever in the UNIX-y hierarchy it lives, it's packages are going to be installed underneath it, e.g /opt/GNUstep, /usr/GNUstep, etc. Classically, on UNIX-y systems ('cause it can run on Windows, too) the preferred spot is /usr/GNUstep. This was likely chosen by the original authors thinking "Hey, that's what X11 did...". This is a concern for me, not because GNUstep is "big" and will cause "pollution," but because it is _different_ than what the FHS was designed for. __armando -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 15:56 ` Armando Di Cianno @ 2004-09-20 19:52 ` Malte S. Stretz 0 siblings, 0 replies; 59+ messages in thread From: Malte S. Stretz @ 2004-09-20 19:52 UTC (permalink / raw To: gentoo-dev On Monday 20 September 2004 17:56 CET Armando Di Cianno wrote: > Just to be ontologically aligned with those that created the NeXTStep > hierarchy, OS X (NeXTStep/OpenStep's logical descendants [alongside > GNUstep]) has it's own UNIX-y/FHS-y hierarchy, from the BSD tools, > _and_ a NeXT-y hierarchy. Seems like GNUstep is a complicated one. I have no idea how it looks like, but to mee it sounds like a whole different subsystem on top of the Linux base? (Probably somehow like the Kolab server which too wants to create its own "root" somewhere, the default being /kolab). I must admit that I have no idea how that fits in (if it can't be split up into something FHS-like). But something like this sounds like a candidate for /opt to me. 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 8:48 ` Paul de Vrieze 2004-09-20 9:47 ` Malte S. Stretz @ 2004-09-20 15:40 ` Dan Armak 2004-09-20 18:30 ` Paul de Vrieze 1 sibling, 1 reply; 59+ messages in thread From: Dan Armak @ 2004-09-20 15:40 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1156 bytes --] On Monday 20 September 2004 11:48, Paul de Vrieze wrote: > 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. 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. Since the issue's been raised, I've nothing against this proposal. We want to counter the possible future problem of other packages following kde's lead and supporting multiple versions in separate directories, because many directories under /usr really is messy. E.g., create a /usr/packages and put qt, kde and anything else there (/usr/packages/kde/3.2; ...). Who wants to take this proposal to the FHS people? :-) -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 15:40 ` Dan Armak @ 2004-09-20 18:30 ` Paul de Vrieze 2004-09-20 19:45 ` Malte S. Stretz 0 siblings, 1 reply; 59+ messages in thread From: Paul de Vrieze @ 2004-09-20 18:30 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1231 bytes --] On Monday 20 September 2004 17:40, Dan Armak wrote: > On Monday 20 September 2004 11:48, Paul de Vrieze wrote: > > 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. 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. > > Since the issue's been raised, I've nothing against this proposal. We want > to counter the possible future problem of other packages following kde's > lead and supporting multiple versions in separate directories, because many > directories under /usr really is messy. > > E.g., create a /usr/packages and put qt, kde and anything else there > (/usr/packages/kde/3.2; ...). Who wants to take this proposal to the FHS > people? :-) I'll propose it to them in the case that there are more people that support this. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 18:30 ` Paul de Vrieze @ 2004-09-20 19:45 ` Malte S. Stretz 0 siblings, 0 replies; 59+ messages in thread From: Malte S. Stretz @ 2004-09-20 19:45 UTC (permalink / raw To: gentoo-dev On Monday 20 September 2004 20:30 CET Paul de Vrieze wrote: > On Monday 20 September 2004 17:40, Dan Armak wrote: > > On Monday 20 September 2004 11:48, Paul de Vrieze wrote: > > > 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. 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. > > > > Since the issue's been raised, I've nothing against this proposal. We > > want to counter the possible future problem of other packages following > > kde's lead and supporting multiple versions in separate directories, > > because many directories under /usr really is messy. > > > > E.g., create a /usr/packages and put qt, kde and anything else there > > (/usr/packages/kde/3.2; ...). Who wants to take this proposal to the > > FHS people? :-) > > I'll propose it to them in the case that there are more people that > support this. To me the Carsten's proposal feels better. Ie. split big "packages" into /usr/{bin,lib,share,doc,man}/<package>/<version>. This if course could be written down in the FHS so those big packages make it possible to be split up in such a way :) 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:37 ` Dan Armak 2004-09-19 21:23 ` Malte S. Stretz @ 2004-09-19 22:35 ` Joshua J. Berry 2004-09-20 4:10 ` Dan Armak ` (2 more replies) 1 sibling, 3 replies; 59+ messages in thread From: Joshua J. Berry @ 2004-09-19 22:35 UTC (permalink / raw To: Dan Armak; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2433 bytes --] On Sun, Sep 19, 2004 at 11:37:55PM +0300, Dan Armak wrote: > On Sunday 19 September 2004 23:26, Joshua J. Berry wrote: > > > and (b) they are both heavily-bloated, > Bloated in what respect? Size, speed? And what does it have to do with where > we install them to? Size (specifically, number of files). For example: condor@alnath /usr/kde/3.3/bin> ls |wc -l 368 condor@alnath /usr/kde/3.3/lib> ls |wc -l 733 That could pollute the /usr hierarchy quite a bit, which is why I think moving it to straight /usr is a bad idea. > > and you probably don't want to > > pollute /usr... > It's true that I don't want to, only I don't see a better solution. > > If there's a general consensus on moving to /opt I can live with that, because > it doesn't affect the ebuilds/eclasses/results one bit. It's just that it's > entirely inconsistent with the way we're using /opt right now. Perhaps we need to reevaluate how we're using /opt. I'm fine with the current /usr/kde/<version> scheme, but the FHS says that's a no-no. But, they say /opt/<package> is perfectly OK for "add-on" software. From an FHS perspective, the only question is whether or not KDE constitutes "add-on" software. We could have a flamewar on that question for the next 10 years and not get anywhere. ;) > And what if, in a year from now, twenty other projects will decide it's good > for the users to allow many versions to be installed side by side? Will we > move everything to /opt? My point here is that kde itself is not special in > any way (although qt arguably is, since you do want different qt2 and qt3 > programs side by side, but then the qt libraries could live together in /usr > with some effort). It's just that kde users asked for this functionality a > lot, so I added it. Apart from running two stable trees, kde developers use > this to run a stable tree and cvs HEAD. No, it's not special, but I think most people probably won't want a PATH variable that's 10,000 directories long. ;) The only thing that makes it "special" IMHO is how big it is. For smaller packages, it would probably just be easier to do something similar to what we do right now for GIMP and rename the binaries (you're only talking a few, not hundreds as would be the case with KDE). -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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 6:09 ` Joshua J. Berry 2004-09-20 16:22 ` Carsten Lohrke 2004-09-21 4:58 ` Joel Konkle-Parker 2 siblings, 2 replies; 59+ messages in thread From: Dan Armak @ 2004-09-20 4:10 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 872 bytes --] On Monday 20 September 2004 01:35, Joshua J. Berry wrote: > No, it's not special, but I think most people probably won't want a PATH > variable that's 10,000 directories long. ;) The only thing that makes it > "special" IMHO is how big it is. That isn't affected by our choice of /usr/kde or /opt. 10,000 PATH dirs under /opt are equally as bad. So I don't see your point here? Is it that you want to decrease the sheer amount of files in the /usr filesystem? As far as I'm concerned, all portage-installed packages ought to go in /usr except for those that go in /bin /lib etc; the usage of /opt has so far meant the package was lacking in some respect. -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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 1 sibling, 1 reply; 59+ messages in thread From: Mike Frysinger @ 2004-09-20 4:27 UTC (permalink / raw To: gentoo-dev On Monday 20 September 2004 12:10 am, Dan Armak wrote: > the usage of /opt has so far > meant the package was lacking in some respect. no, the gentoo policy of putting binary-only packages in /opt is by no means a portage limitation -mike -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 4:27 ` Mike Frysinger @ 2004-09-20 4:47 ` Luke-Jr 0 siblings, 0 replies; 59+ messages in thread From: Luke-Jr @ 2004-09-20 4:47 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 358 bytes --] On Monday 20 September 2004 4:27 am, Mike Frysinger wrote: > no, the gentoo policy of putting binary-only packages in /opt is by no > means a portage limitation Just a note, it's binary packages in /opt, not merely binary-only... mozilla-bin, openoffice-bin, etc certainly aren't binary-*only*... -- Luke-Jr Developer, Utopios http://utopios.org/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 4:10 ` Dan Armak 2004-09-20 4:27 ` Mike Frysinger @ 2004-09-20 6:09 ` Joshua J. Berry 2004-09-20 9:05 ` Paul de Vrieze 2004-09-20 15:55 ` Sami Samhuri 1 sibling, 2 replies; 59+ messages in thread From: Joshua J. Berry @ 2004-09-20 6:09 UTC (permalink / raw To: Dan Armak; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1940 bytes --] On Mon, Sep 20, 2004 at 07:10:02AM +0300, Dan Armak wrote: > On Monday 20 September 2004 01:35, Joshua J. Berry wrote: > > No, it's not special, but I think most people probably won't want a PATH > > variable that's 10,000 directories long. ;) The only thing that makes it > > "special" IMHO is how big it is. > That isn't affected by our choice of /usr/kde or /opt. 10,000 PATH dirs > under /opt are equally as bad. So I don't see your point here? Assuming I understood you correctly, you made the point that if KDE goes into /opt and gets its own directory, others might want to do that too ... My point is that KDE should be an exception to the "packages-shouldn't-have-their-own-dirs" rule because it's so big. > Is it that you > want to decrease the sheer amount of files in the /usr filesystem? I would like to keep the pollution in /usr down, yes. > As far as > I'm concerned, all portage-installed packages ought to go in /usr except for > those that go in /bin /lib etc; the usage of /opt has so far meant the > package was lacking in some respect. I don't know. Maybe it makes more sense to me because that's just always the way I've installed KDE -- separate from everything else. I can see the benefits of the "everything-in-/usr" argument too (pollution notwithstanding). It seems like a lot of people prefer to have Qt/KDE split out from the normal /usr tree. But some people are complaining because /usr/kde doesn't follow the FHS. /opt keeps both groups happy. It keeps KDE separate (and lets you install multiple versions side-by-side), and it follows the FHS. Except now we have a third group of people who don't like /opt ... and I guess I don't understand why that is. What do people have against /opt (yes, I know about current Gentoo policy)? -- Joshua J. Berry "I haven't lost my mind -- it's backed up on tape somewhere." -- /usr/games/fortune [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 6:09 ` Joshua J. Berry @ 2004-09-20 9:05 ` Paul de Vrieze 2004-09-20 15:55 ` Sami Samhuri 1 sibling, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-20 9:05 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 835 bytes --] On Monday 20 September 2004 08:09, Joshua J. Berry wrote: > /opt keeps both groups happy. It keeps KDE separate (and lets you > install multiple versions side-by-side), and it follows the FHS. > Except now we have a third group of people who don't like /opt ... and > I guess I don't understand why that is. What do people have against > /opt (yes, I know about current Gentoo policy)? There are two reasons: - It is against gentoo policy - It is against the FHS as KDE is not a standalone package, but it has a significant amount of dependant packages. One of the rules for /opt is that no package in /usr should depend on it. As dependend packages are installed in /usr this is clearly a violation. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 6:09 ` Joshua J. Berry 2004-09-20 9:05 ` Paul de Vrieze @ 2004-09-20 15:55 ` Sami Samhuri 1 sibling, 0 replies; 59+ messages in thread From: Sami Samhuri @ 2004-09-20 15:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1092 bytes --] * On Sun Sep-19-2004 at 11:09:36 PM -0700, Joshua J. Berry said: > On Mon, Sep 20, 2004 at 07:10:02AM +0300, Dan Armak wrote: > > > Is it that you > > want to decrease the sheer amount of files in the /usr filesystem? > > I would like to keep the pollution in /usr down, yes. Why? (Not trolling, just genuinely curious.) Do you mean KDE being in /usr at all, or just not in /usr/kde/? I think it makes sense to keep it under /usr, where everything else is installed. I'd rather not have packages installed in /opt at all. Granted, I think there could be a better solution (I don't like package subdirs directly under /usr either) but I don't think /opt is it. /opt conveys nothing to me. /usr/prog, /usr/app, /usr/soft, it's hard to think of a meaningful name that's not more than 4 chars, but I think that's a good solution. A symlink from /usr/bin/kde to /usr/XXX/kde/3.3/bin would take care of the $PATH problem, I think. Sorry for jumping in, and sorry if I've said something ridiculous here. I'm new to Gentoo but this interests me. -- Sami Samhuri [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 22:35 ` Joshua J. Berry 2004-09-20 4:10 ` Dan Armak @ 2004-09-20 16:22 ` Carsten Lohrke 2004-09-20 16:36 ` Malte S. Stretz 2004-09-20 16:37 ` Dan Armak 2004-09-21 4:58 ` Joel Konkle-Parker 2 siblings, 2 replies; 59+ messages in thread From: Carsten Lohrke @ 2004-09-20 16:22 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1099 bytes --] On Monday 20 September 2004 00:35, Joshua J. Berry wrote: > On Sun, Sep 19, 2004 at 11:37:55PM +0300, Dan Armak wrote: > > On Sunday 19 September 2004 23:26, Joshua J. Berry wrote: > > > and (b) they are both heavily-bloated, > > > > Bloated in what respect? Size, speed? And what does it have to do with > > where we install them to? > > Size (specifically, number of files). For example: > > condor@alnath /usr/kde/3.3/bin> ls |wc -l > 368 > condor@alnath /usr/kde/3.3/lib> ls |wc -l > 733 > > That could pollute the /usr hierarchy quite a bit, which is why I think > moving it to straight /usr is a bad idea. I get the point with /usr/kde not conforming to FHS, but imho the size of packages has nothing to do with their location. The main questions are, if the data is variable or static, shared or not. Could you enlight me about that? I don't think that it should go in /opt, since the kde stuff is simply not more or less optional as everythin else. I wonder if it would be better to have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!? Carsten [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:42 ` Carsten Lohrke 2004-09-20 16:37 ` Dan Armak 1 sibling, 2 replies; 59+ messages in thread From: Malte S. Stretz @ 2004-09-20 16:36 UTC (permalink / raw To: gentoo-dev On Monday 20 September 2004 18:22 CET Carsten Lohrke wrote: > I get the point with /usr/kde not conforming to FHS, but imho the size of > packages has nothing to do with their location. The main questions are, > if the data is variable or static, shared or not. Could you enlight me > about that? > > I don't think that it should go in /opt, since the kde stuff is simply > not more or less optional as everythin else. I wonder if it would be > better to have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!? 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? 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:42 ` Carsten Lohrke 1 sibling, 1 reply; 59+ messages in thread From: Dan Armak @ 2004-09-20 16:44 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1238 bytes --] 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? 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? -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 16:44 ` Dan Armak @ 2004-09-20 17:19 ` Malte S. Stretz 2004-09-20 17:36 ` Dan Armak 0 siblings, 1 reply; 59+ messages in thread From: Malte S. Stretz @ 2004-09-20 17:19 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 17:19 ` Malte S. Stretz @ 2004-09-20 17:36 ` Dan Armak 2004-09-20 22:58 ` foser 0 siblings, 1 reply; 59+ messages in thread From: Dan Armak @ 2004-09-20 17:36 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2719 bytes --] On Monday 20 September 2004 20:19, Malte S. Stretz wrote: > 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 see. > > 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? My point was that since lib is meant for, well, libraries (and occasional binaries), it'd be inappropriate to put things like docs under it. Just inelegant, and people wouldn't expect it. Especially in view of the filesystem sharing scenario you outlined. > > > 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. Definitely - if KDE makes it as easy as KDEDIRS, I'd vote for such a solution too in the longterm. > > 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. Seems like it to me, too. > > 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. Agreed. > 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? No idea. I seem to remember gnome 1.4 and 2.0 coexisted back in the day, but don't remember how... Any gnome devs reading this thread? ;-) -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 17:36 ` Dan Armak @ 2004-09-20 22:58 ` foser 0 siblings, 0 replies; 59+ messages in thread From: foser @ 2004-09-20 22:58 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 783 bytes --] On Mon, 2004-09-20 at 20:36 +0300, Dan Armak wrote: > > 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? > No idea. I seem to remember gnome 1.4 and 2.0 coexisted back in the day, but > don't remember how... Any gnome devs reading this thread? ;-) GNOME 2 versions all. it's installed dirs & libs : /usr/lib/libgnomeui-2.0.so, /usr/include/libgnome-2.0/, etc. GNOME 1 didn't version at all so that didn't get in the way either. We do not support having several versions in the same SLOT (literal meaning) coexist like KDE does atm. eg. people can't have gnome 2.2 & 2.6 co-existing on a default install, but in my opinion there is no good reason to support that. - foser [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 16:36 ` Malte S. Stretz 2004-09-20 16:44 ` Dan Armak @ 2004-09-20 17:42 ` Carsten Lohrke 1 sibling, 0 replies; 59+ messages in thread From: Carsten Lohrke @ 2004-09-20 17:42 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 702 bytes --] On Monday 20 September 2004 18:36, Malte S. Stretz wrote: > 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? Um, this wasn't meant to be a suggestion. My suggestion is to let it be as it is now, since a) it's not that important imho (me wonders about the size of this thread) and b) the above idea would probably cause trouble with a lot of hardcoded subdir's in Makefiles. To those mentioning /usr/X11R6/ as an example. I think I read that the xorg guys planned to move away from this location and follow the FHS?! Carsten [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 16:22 ` Carsten Lohrke 2004-09-20 16:36 ` Malte S. Stretz @ 2004-09-20 16:37 ` Dan Armak 2004-09-20 17:35 ` Carsten Lohrke 1 sibling, 1 reply; 59+ messages in thread From: Dan Armak @ 2004-09-20 16:37 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 939 bytes --] On Monday 20 September 2004 19:22, Carsten Lohrke wrote: > I don't think that it should go in /opt, since the kde stuff is simply not > more or less optional as everythin else. I wonder if it would be better to > have /usr/lib/kde/x.y, /usr/share/kde/x.y,... directories!? I've never seen the point of it. The kde directories include things under share/, like various docs, that make absolutely no sense somewhere under /usr/lib. And FHS forbids putting them there at least as much as it forbids creating a /usr/kde. I think that if we have to move, a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns' apparently being replaced by a four-letter name - could someone enlighten me why that would be necessary?) -- Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 16:37 ` Dan Armak @ 2004-09-20 17:35 ` Carsten Lohrke 2004-09-20 18:52 ` Paul de Vrieze 0 siblings, 1 reply; 59+ messages in thread From: Carsten Lohrke @ 2004-09-20 17:35 UTC (permalink / raw To: gentoo-dev; +Cc: danarmak [-- Attachment #1: Type: text/plain, Size: 1342 bytes --] On Monday 20 September 2004 18:37, Dan Armak wrote: > The kde directories include things under > share/, like various docs, that make absolutely no sense somewhere > under /usr/lib. Exactly this does not conform to the FHS iirc. # The following directories, or symbolic links to directories, must be # in /usr/share, if the corresponding subsystem is installed: #dict, doc, games, info, locale, nls, sgml, terminfo, database, tmac, xml, #zoneinfo #It is recommended that application-specific, architecture-independent #directories be placed here. http://www.pathname.com/fhs/pub/fhs-2.3.html Which means e.g. kde's docs should go in /usr/share/doc/kde. Since we want to allow multiple kde versions, it would need to be either /usr/share/doc/kde/X.Y or /usr/share/doc/kdeX.Y. We do the latter for most ebuilds, since it is - in case of docs at least - policy to install them in ${D}/usr/share/docs/${PF} > I think that if we have to move, > a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns' apparently > being replaced by a four-letter name - could someone enlighten me why that > would be necessary?) /usr/packages/whatever is as FHS "conform" as /usr/kde. From my point of view the kde location is not a big and if we want to change something, let's do it with qt/kde 4. Carsten [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 17:35 ` Carsten Lohrke @ 2004-09-20 18:52 ` Paul de Vrieze 2004-09-20 19:17 ` Carsten Lohrke 0 siblings, 1 reply; 59+ messages in thread From: Paul de Vrieze @ 2004-09-20 18:52 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2086 bytes --] On Monday 20 September 2004 19:35, Carsten Lohrke wrote: > On Monday 20 September 2004 18:37, Dan Armak wrote: > > The kde directories include things under > > share/, like various docs, that make absolutely no sense somewhere > > under /usr/lib. > > Exactly this does not conform to the FHS iirc. > > # The following directories, or symbolic links to directories, must be > # in /usr/share, if the corresponding subsystem is installed: > #dict, doc, games, info, locale, nls, sgml, terminfo, database, tmac, xml, > #zoneinfo > #It is recommended that application-specific, architecture-independent > #directories be placed here. > http://www.pathname.com/fhs/pub/fhs-2.3.html > > Which means e.g. kde's docs should go in /usr/share/doc/kde. Since we want > to allow multiple kde versions, it would need to be > either /usr/share/doc/kde/X.Y or /usr/share/doc/kdeX.Y. We do the latter > for most ebuilds, since it is - in case of docs at least - policy to > install them in ${D}/usr/share/docs/${PF} No, it sais that those dirs should exist. Not that all docs should go there. In any case following that kind of policy would be pain in the ass for many packages that have different opinions. > > > I think that if we have to move, > > a /usr/packages/{kde,qt}/<version> pattern is best. ('patterns' > > apparently being replaced by a four-letter name - could someone enlighten > > me why that would be necessary?) > > /usr/packages/whatever is as FHS "conform" as /usr/kde. Probably more as it is not indirect, the FHS does not say anywhere that more dirs are not allowed they just specify the minimal set. It is perfectly legal to make aditions that do not violate the rules in the FHS. The /usr/packages idea does not violate this idea. > From my point of view the kde location is not a big and if we want to > change something, let's do it with qt/kde 4. I don't mind keeping things this way, but people seem to want it. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-20 18:52 ` Paul de Vrieze @ 2004-09-20 19:17 ` Carsten Lohrke 2004-09-21 10:47 ` [gentoo-dev] " Duncan 0 siblings, 1 reply; 59+ messages in thread From: Carsten Lohrke @ 2004-09-20 19:17 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1709 bytes --] On Monday 20 September 2004 20:52, Paul de Vrieze wrote: > No, it sais that those dirs should exist. Not that all docs should go > there. In any case following that kind of policy would be pain in the ass > for many packages that have different opinions. Imho it is a better to follow a standard as strict as possible. The next one sees it a bit more lax and in the end you can forget the standard. > > /usr/packages/whatever is as FHS "conform" as /usr/kde. > > Probably more as it is not indirect, the FHS does not say anywhere that > more dirs are not allowed they just specify the minimal set. #Chapter 4. The /usr Hierarchy #Purpose #/usr is the second major section of the filesystem. /usr is shareable, #read-only data. That means that /usr should be shareable between various #FHS-compliant hosts and must not be written to. Any information that is #host-specific or varies with time is stored elsewhere. #Large software packages must not use a direct subdirectory under the /usr #hierarchy O.k., that doesn't forbid to add another directory and to use this one as a new base, but it still doesn't make sense to me. I see this formulation more as a gap in the standard. Either unintended or as a backwards compatibility thing to get everyone into the boat. > > From my point of view the kde location is not a big and if we want to > > change something, let's do it with qt/kde 4. > > I don't mind keeping things this way, but people seem to want it. But they don't have to deal with the implications. Also users with a larger install base may have their backup scripts and so on, so such a decision should not be made for kde 3.x. Carsten. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-20 19:17 ` Carsten Lohrke @ 2004-09-21 10:47 ` Duncan 2004-09-21 11:02 ` Duncan 2004-09-21 12:05 ` Carsten Lohrke 0 siblings, 2 replies; 59+ messages in thread From: Duncan @ 2004-09-21 10:47 UTC (permalink / raw To: gentoo-dev Carsten Lohrke posted <200409202117.34236.carlo@gentoo.org>, excerpted below, on Mon, 20 Sep 2004 21:17:26 +0200: > #Chapter 4. The /usr Hierarchy > > #Purpose > > #/usr is the second major section of the filesystem. /usr is shareable, > #read-only data. That means that /usr should be shareable between various > #FHS-compliant hosts and must not be written to. Any information that is > #host-specific or varies with time is stored elsewhere. > > #Large software packages must not use a direct subdirectory under the /usr > #hierarchy > > O.k., that doesn't forbid to add another directory and to use this one as a > new base, but it still doesn't make sense to me. I see this formulation more > as a gap in the standard. Either unintended or as a backwards compatibility > thing to get everyone into the boat. OK, since nobody else has brought this up, I must be reading something wrong, but I don't see what the problem is here. (I also repeat myself a bit below. However, it's so obvious here, I find it difficult to believe that someone else hasn't seen it either. Yet the fact remains I haven't seen it mentioned yet, in what has become a rather long thread. That must mean it's non-obvious, despite what it seems here, so excuse a bit of belaboring of the point in my attempt to make it equally obvious to others! <g>) As I see it, we are NOT putting "large packages" directly under /usr, because the "large packages" in question are versioned (slotted per individual directory) and under /kde. As I read the spec, /usr/kde is already a level of indirection, because our packages are (perfectly logically, it seems to me) laid out beneath /usr/kde and not directly in /usr. IOW, the way I read it, /usr/kde-3.3 would be a violation, but /usr/kde/3.3 isn't, because it's already a level of indirection. Just because we've chosen to only put KDE related packages at that specific case of the indirection level means nothing. The packages are STILL not directly under /usr. Now, I WOULD have an issue with /usr/kde-3.3, and /usr/kde-3.2, and /usr/kde-4.0, etc (and noting that with other distribs there'd likely be only a single version-slot under /usr/kde). That's just a ridiculous proliferation directly under /usr and I'm sure everyone would agree. However, as has already come up, given the large (both in size and in dependencies) tree that is KDE, I see nothing at all wrong with putting that dir itself (not the packages or slots in it) directly under /usr, nor can I see how it conflicts with the quoted rules above. Again, for those distribs without multiple KDE slots, a single /usr/kde would indeed be a violation, as it's just a single (meta-)package. However, the fact that we've chosen to group a very large package set that under our (meta-)distribution could reasonably be several multiples of the size of /most/ distribution's kde, under a /usr direct subdir with each instance of our multiples below that, doesn't seem to me to be in conflict with the FHS at all. Again, as others have pointed out in other contexts, there's nothing wrong with adding /more/ dirs. We just have to have the basics and observe the rules about what goes in them. Putting it another way, we've already proposed /usr/packages. Now, if we got a whole bunch of packages, there'd be nothing wrong with splitting that into say /usr/pkg-a-m, and /usr/pkg-n-z, right? OK, what if there were more k- packages than all the others combined? There wouldn't be a problem with /usr/pkg-but-k and /usr/pkg-k, right? We've just done gone the logical next step. Because KDE is multi-slotted, and with KDE as big as it is already and the slotting essentially multiplying that X times, we've just created what is essentially /usr/pkg-kde, only without the pkg- part. I still contend that we aren't putting our packages directly under /usr, as each package is in fact in a slot in kde in /usr. Where's the FHS violation? I can't see it? -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-21 10:47 ` [gentoo-dev] " Duncan @ 2004-09-21 11:02 ` Duncan 2004-09-21 12:05 ` Carsten Lohrke 1 sibling, 0 replies; 59+ messages in thread From: Duncan @ 2004-09-21 11:02 UTC (permalink / raw To: gentoo-dev Duncan posted <pan.2004.09.21.10.47.48.152334@cox.net>, excerpted below, on Tue, 21 Sep 2004 03:47:49 -0700: > OK, since nobody else has brought this up, I must be reading something > wrong, but I don't see what the problem is here. OK, so since I wrote that, I now see that Paul mentioned it. However, no replies yet. -- Duncan - List replies preferred. No HTML msgs. "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-21 10:47 ` [gentoo-dev] " Duncan 2004-09-21 11:02 ` Duncan @ 2004-09-21 12:05 ` Carsten Lohrke 1 sibling, 0 replies; 59+ messages in thread From: Carsten Lohrke @ 2004-09-21 12:05 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1452 bytes --] On Tuesday 21 September 2004 12:47, Duncan wrote: > IOW, the way I read it, /usr/kde-3.3 would be a violation, but > /usr/kde/3.3 isn't, because it's already a level of indirection. [..] > Where's the FHS violation? I can't see it? Yes Duncan, you're right about the KDE path. Didn't had in mind that kde/ itself is a level of indirection and x.y/ the real package directory. That's o.k., if you read the FHS in a way that other than the mentioned directories in /usr are allowed. If you see it from a strict standardization perspective, this shouldn't be the case. If every distro adds directories life doesn't get easier for people using more than one distro or having to switch to another. Reliable paths ease writing and maintaining of all sorts of scripts, too. This is my very reason to let kde were it is (for now), btw.. You undermine a standard, if you expoit every gap you can find in it. >However, as has already come up, given the large (both in size and in >dependencies) tree that is KDE, I see nothing at all wrong with putting >that dir itself (not the packages or slots in it) directly under /usr, nor >can I see how it conflicts with the quoted rules above. This is the amusing point. I don't really get the argument to move /usr/kde(/x.y) elsewhere because of its size. The way it is now is the most simple way to put the whole kde stuff on a extra partition, if you like to. Carsten [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-19 22:35 ` Joshua J. Berry 2004-09-20 4:10 ` Dan Armak 2004-09-20 16:22 ` Carsten Lohrke @ 2004-09-21 4:58 ` Joel Konkle-Parker 2004-09-21 9:49 ` Paul de Vrieze 2 siblings, 1 reply; 59+ messages in thread From: Joel Konkle-Parker @ 2004-09-21 4:58 UTC (permalink / raw To: gentoo-dev Joshua J. Berry wrote: > No, it's not special, but I think most people probably won't want a PATH > variable that's 10,000 directories long. Note that this is also a usability issue. I recently helped a friend set up Gentoo + KDE (first Linux experience), and the default PATH did not include the /usr/kde/x.x/bin dir, so he couldn't open KDE progs from the command line. This may be an easy bug or configuration error in /etc/env.d, but the issue remains that it is easier for all the programs to be located in /usr/bin. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3@msstate.edu] -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-21 4:58 ` Joel Konkle-Parker @ 2004-09-21 9:49 ` Paul de Vrieze 0 siblings, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-21 9:49 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1066 bytes --] On Tuesday 21 September 2004 06:58, Joel Konkle-Parker wrote: > Joshua J. Berry wrote: > > No, it's not special, but I think most people probably won't want a PATH > > variable that's 10,000 directories long. > > Note that this is also a usability issue. I recently helped a friend set > up Gentoo + KDE (first Linux experience), and the default PATH did not > include the /usr/kde/x.x/bin dir, so he couldn't open KDE progs from the > command line. > > This may be an easy bug or configuration error in /etc/env.d, but the > issue remains that it is easier for all the programs to be located in > /usr/bin. The contents of /etc/env.d/47kdepaths-3.3.0 on my computer (automatically installed): PATH=/usr/kde/3.3/bin ROOTPATH=/usr/kde/3.3/sbin:/usr/kde/3.3/bin LDPATH=/usr/kde/3.3/lib CONFIG_PROTECT=/usr/kde/3.3/share/config:/usr/kde/3.3/env:/usr/kde/3.3/shutdown Of course this only works after a reboot or env-update and relogin. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:16 ` Dan Armak 2004-09-19 20:26 ` Joshua J. Berry @ 2004-09-20 7:49 ` Simon Watson 1 sibling, 0 replies; 59+ messages in thread From: Simon Watson @ 2004-09-20 7:49 UTC (permalink / raw To: danarmak; +Cc: gentoo-dev Dan Armak wrote: > The FHS says about /usr: "Large software packages must not use a direct > subdirectory under the /usr hierarchy." I agree this rules out what we're > doing. The problem is, noone ever proposed a better (more FHS-compliant) > solution. > How about a USE flag or such like, for specifying FHS compliancy? Whereby if specified QT/KDE would be installed as per FHS, but with a warning that this means SLOTting no longer works? Simon -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:06 ` Dan Armak 2004-09-19 20:07 ` Joshua J. Berry @ 2004-09-19 20:09 ` Paul de Vrieze 2004-09-28 2:51 ` [gentoo-dev] " John Croisant 2 siblings, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-19 20:09 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1089 bytes --] On Sunday 19 September 2004 22:06, Dan Armak wrote: > /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. > > If it's a matter of simply moving the /usr/{qt,kde}/$VERSION directories > anywhere else, that's as simple as setting a few env variables before an > emerge, and changing their default vaules in eclasses or whereever. I'm also still not convinced that this is really against the FHS. I think this could be a border case that just falls in or out the FHS. The FHS forbids direct children directories of /usr, but /usr/kde/3.3 is not a direct child. Maybe it is not in the exact spirit of FHS, but as far as I know the FHS people have also not offered any sensible solution for kde, qt etc. yet. They also DO NOT belong in /opt, as they are not standalone packages (let alone binary which is the gentoo requirement (sort of)) Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-19 20:06 ` Dan Armak 2004-09-19 20:07 ` Joshua J. Berry 2004-09-19 20:09 ` Paul de Vrieze @ 2004-09-28 2:51 ` John Croisant 2004-09-28 8:19 ` Paul de Vrieze 2 siblings, 1 reply; 59+ messages in thread From: John Croisant @ 2004-09-28 2:51 UTC (permalink / raw To: gentoo-dev 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 ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 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 20:32 ` John Croisant 0 siblings, 2 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-28 8:19 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2621 bytes --] 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 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 expects KDEDIR(S) to work the way it does currently. I know it is not 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 the main reason for the current setup is based on the kde/qt setup. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 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 1 sibling, 1 reply; 59+ messages in thread From: Peter Ruskin @ 2004-09-28 9:24 UTC (permalink / raw To: gentoo-dev On Tuesday 28 September 2004 09:19, Paul de Vrieze wrote: > Do you realize that this would amount to serious patches on kde. KDE > expects KDEDIR(S) to work the way it does currently. I know it is not > ideal, but neither is the FHS. Well I think it *is* ideal the way we have it - that was one of the many things that attracted me to Gentoo in the first place. It's the most sensible way I've come across for organizing KDE/Qt and we should not even consider abandoning it. -- Peter ======================================================================== Gentoo Linux: Portage 2.0.50-r11. kernel-2.6.8-gentoo-r4. i686 AMD Athlon(tm) XP 3200+. gcc(GCC): 3.4.2. KDE: 3.3.0. Qt: 3.3.3. ======================================================================== -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-28 9:24 ` Peter Ruskin @ 2004-09-28 9:37 ` Paul de Vrieze 0 siblings, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-28 9:37 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 983 bytes --] On Tuesday 28 September 2004 11:24, Peter Ruskin wrote: > On Tuesday 28 September 2004 09:19, Paul de Vrieze wrote: > > Do you realize that this would amount to serious patches on kde. KDE > > expects KDEDIR(S) to work the way it does currently. I know it is not > > ideal, but neither is the FHS. > > Well I think it *is* ideal the way we have it - that was one of the > many things that attracted me to Gentoo in the first place. It's the > most sensible way I've come across for organizing KDE/Qt and we should > not even consider abandoning it. Ideal to me would be a way that has the same power as the current way, but without getting on the edge of the FHS (so also pleasing the people who value that greatly). I agree however that this is probably the best way to do it as long as the FHS does not really offer support for our way of operation. Paul -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-28 8:19 ` Paul de Vrieze 2004-09-28 9:24 ` Peter Ruskin @ 2004-09-28 20:32 ` John Croisant 2004-09-29 9:07 ` Paul de Vrieze 1 sibling, 1 reply; 59+ messages in thread From: John Croisant @ 2004-09-28 20:32 UTC (permalink / raw To: gentoo-dev On Tue, 28 Sep 2004 10:19:29 +0200, Paul de Vrieze <pauldv@gentoo.org> wrote: > > Do you realize that this would amount to serious patches on kde. KDE > expects KDEDIR(S) to work the way it does currently. I know it is not > ideal, but neither is the FHS. I don't pretend to be an expert on how KDE works, which is why I ask: why couldn't you add the scattered directories to KDEDIRS? The documentation I have read suggests that KDE will search all directories in KDEDIRS for the files it needs. Am I missing something? I assume that there is some sort of conflict such that it wouldn't work for KDE to have all versions in its path. Is it possible to tell an application which KDEDIRS to use (again assuming that KDEDIRS would have to be different for different versions of KDE), without patching the application or KDE? Could a script be written that would define KDEDIRS for an application call? Is there a way to automatically detect whether an application uses one version of KDE or another? Could some function be easily added to all KDE-related ebuilds, to create a wrapper script for the applications? -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-28 20:32 ` John Croisant @ 2004-09-29 9:07 ` Paul de Vrieze 0 siblings, 0 replies; 59+ messages in thread From: Paul de Vrieze @ 2004-09-29 9:07 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] On Tuesday 28 September 2004 22:32, John Croisant wrote: > I don't pretend to be an expert on how KDE works, which is why I ask: > why couldn't you add the scattered directories to KDEDIRS? The > documentation I have read suggests that KDE will search all > directories in KDEDIRS for the files it needs. Am I missing something? > > I assume that there is some sort of conflict such that it wouldn't > work for KDE to have all versions in its path. Is it possible to tell > an application which KDEDIRS to use (again assuming that KDEDIRS would > have to be different for different versions of KDE), without patching > the application or KDE? Could a script be written that would define > KDEDIRS for an application call? Is there a way to automatically > detect whether an application uses one version of KDE or another? > Could some function be easily added to all KDE-related ebuilds, to > create a wrapper script for the applications? The elements of the KDEDIRS directory is supposed to be a root directory (under which the bin,share,lib,include etc. directories should be located). Scattering is not an option. To detect which kde version is used one could use ldd and check the libkdecore version. Paul > > -- > gentoo-dev@gentoo.org mailing list -- Paul de Vrieze Gentoo Developer Mail: pauldv@gentoo.org Homepage: http://www.devrieze.net [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] any interest in removing /usr/qt and /usr/kde ? 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:06 ` Dan Armak @ 2004-09-19 21:55 ` Luke-Jr 2004-09-19 23:06 ` [gentoo-dev] " Thomas Weidner 2 siblings, 1 reply; 59+ messages in thread From: Luke-Jr @ 2004-09-19 21:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1598 bytes --] On Sunday 19 September 2004 7:50 pm, Thomas Weidner wrote: > I think all know /usr/qt and /usr/kde conflicts with the FHS, but it's > there in order to make it possible to have several versions of kde/qt > installed side by side. If there was a way to make qt and kde > installations FHS compilant without removing the possibility to have > several versions installed side by side,whould there be any interest to > add it to portage or want gentoo developers to stick with the current > solution? I know the current version works, but it conflicts with the > FHS (and therefore with the LSB). IIRC, having /mnt as anything but an empty directory conflicts with the FHS also. Gentoo uses /mnt as FHS's /media On Sunday 19 September 2004 8:16 pm, Dan Armak wrote: > The FHS says about /usr: "Large software packages must not use a direct > subdirectory under the /usr hierarchy." I agree this rules out what we're > doing. The problem is, noone ever proposed a better (more FHS-compliant) > solution. So is XFree86/X.org in violation of this also? On Sunday 19 September 2004 8:37 pm, Dan Armak wrote: > My point here is that kde itself is not special in any way (although qt > arguably is, since you do want different qt2 and qt3 programs side by side, > but then the qt libraries could live together in /usr with some effort). No need for such versioning of Qt 2 and 3 libs as far as I can tell. Isn't Qt 3 binary compatible with 2? (note: this will soon change with Qt 4 not being compatible with either) -- Luke-Jr Developer, Utopios http://utopios.org/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-19 21:55 ` [gentoo-dev] " Luke-Jr @ 2004-09-19 23:06 ` Thomas Weidner 2004-09-20 0:03 ` Luke-Jr 0 siblings, 1 reply; 59+ messages in thread From: Thomas Weidner @ 2004-09-19 23:06 UTC (permalink / raw To: gentoo-dev Luke-Jr wrote: > IIRC, having /mnt as anything but an empty directory conflicts with the FHS > also. Gentoo uses /mnt as FHS's /media /mnt : Mount point for a temporarily mounted filesystem Purpose This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run. This directory must not be used by installation programs: a suitable temporary directory not in use by the system must be used instead. > On Sunday 19 September 2004 8:16 pm, Dan Armak wrote: > >>The FHS says about /usr: "Large software packages must not use a direct >>subdirectory under the /usr hierarchy." I agree this rules out what we're >>doing. The problem is, noone ever proposed a better (more FHS-compliant) >>solution. > > > So is XFree86/X.org in violation of this also? FHS says about /usr/X11R6: ``An exception is made for the X Window System because of considerable precedent and widely-accepted practice.'' So it's an exception, _not_ the rule. (pls don't start to ask if kde/qt can also be an exception...not it can not imo) -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-19 23:06 ` [gentoo-dev] " Thomas Weidner @ 2004-09-20 0:03 ` Luke-Jr 2004-09-20 0:55 ` Ciaran McCreesh 0 siblings, 1 reply; 59+ messages in thread From: Luke-Jr @ 2004-09-20 0:03 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 934 bytes --] On Sunday 19 September 2004 11:06 pm, Thomas Weidner wrote: > Luke-Jr wrote: > > IIRC, having /mnt as anything but an empty directory conflicts with the > > FHS also. Gentoo uses /mnt as FHS's /media > > /mnt : Mount point for a temporarily mounted filesystem > Purpose > > This directory is provided so that the system administrator may > temporarily mount a filesystem as needed. The content of this directory > is a local issue and should not affect the manner in which any program > is run. > > This directory must not be used by installation programs: a suitable > temporary directory not in use by the system must be used instead. Exactly. For a *system administrator* to *temporarily* mount a filesystem in. This means 'mount some-temp-filesystem /mnt' temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0 /mnt/floppy; etc' perminantly. -- Luke-Jr Developer, Utopios http://utopios.org/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 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 0 siblings, 2 replies; 59+ messages in thread From: Ciaran McCreesh @ 2004-09-20 0:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 661 bytes --] On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote: | Exactly. For a *system administrator* to *temporarily* mount a | filesystem in. This means 'mount some-temp-filesystem /mnt' | temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0 | /mnt/floppy; etc' perminantly.-- Why have a specific toplevel for that? No need, just use cwd or $HOME. Surely you don't think the FHS is thaaaaat silly? By 'temporary' they've gotta mean 'not always mounted'. Anything else is madness. -- Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox) Mail : ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-20 0:55 ` Ciaran McCreesh @ 2004-09-20 3:50 ` Luke-Jr 2004-09-21 5:10 ` Joel Konkle-Parker 1 sibling, 0 replies; 59+ messages in thread From: Luke-Jr @ 2004-09-20 3:50 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 928 bytes --] On Monday 20 September 2004 12:55 am, Ciaran McCreesh wrote: > On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote: > | Exactly. For a *system administrator* to *temporarily* mount a > | filesystem in. This means 'mount some-temp-filesystem /mnt' > | temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0 > | /mnt/floppy; etc' perminantly.-- > > Why have a specific toplevel for that? No need, just use cwd or $HOME. > Surely you don't think the FHS is thaaaaat silly? If the LSB can be silly enough to require RPM, why can't the FHS be silly enough to require a silly toplevel? > By 'temporary' they've gotta mean 'not always mounted'. And they do... However, the mount point is /mnt, not /mnt/* Also, on many systems, /mnt/cdrom etc *are* always mounted ... as supermount. :) > Anything else is madness. No comment. -- Luke-Jr Developer, Utopios http://utopios.org/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 59+ messages in thread
* [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 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 1 sibling, 1 reply; 59+ messages in thread From: Joel Konkle-Parker @ 2004-09-21 5:10 UTC (permalink / raw To: gentoo-dev Ciaran McCreesh wrote: > On Mon, 20 Sep 2004 00:03:59 +0000 Luke-Jr <luke-jr@utopios.org> wrote: > | Exactly. For a *system administrator* to *temporarily* mount a > | filesystem in. This means 'mount some-temp-filesystem /mnt' > | temporarily, not 'mount /dev/cdrom /mnt/cdrom; mount /dev/fd0 > | /mnt/floppy; etc' perminantly.-- > > Why have a specific toplevel for that? No need, just use cwd or $HOME. > Surely you don't think the FHS is thaaaaat silly? By 'temporary' they've > gotta mean 'not always mounted'. Anything else is madness. > http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT /media : Mount point for removeable media Purpose This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks. Tip Rationale Historically there have been a number of other different places used to mount removeable media such as /cdrom, /mnt or /mnt/cdrom. Placing the mount points for all removeable media directly in the root directory would potentially result in a large number of extra directories in /. Although the use of subdirectories in /mnt as a mount point has recently been common, it conflicts with a much older tradition of using /mnt directly as a temporary mount point. -- Joel Konkle-Parker Webmaster [Ballsome.com] E-mail [jjk3@msstate.edu] -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
* Re: [gentoo-dev] Re: any interest in removing /usr/qt and /usr/kde ? 2004-09-21 5:10 ` Joel Konkle-Parker @ 2004-09-21 17:29 ` Helmar Wieland 0 siblings, 0 replies; 59+ messages in thread From: Helmar Wieland @ 2004-09-21 17:29 UTC (permalink / raw To: gentoo-dev Joel Konkle-Parker schrieb am 21.09.2004 07:10: > http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT > > /media : Mount point for removeable media > Purpose > > This directory contains subdirectories which are used as mount points > for removeable media such as floppy disks, cdroms and zip disks. I entered this into bugzilla quiet some time ago: http://bugs.gentoo.org/show_bug.cgi?id=41519 It became a WONTFIX, since the majority of gentoo devs (which replied to this bug) didn't want to change the behaviour they were familiar with :-( So at least we've got something to do after each baselayout upgrade... -- gentoo-dev@gentoo.org mailing list ^ permalink raw reply [flat|nested] 59+ messages in thread
end of thread, other threads:[~2004-09-29 9:07 UTC | newest] Thread overview: 59+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 ` [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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox