Re: Interpreting FHS
True, but putting the packages directly under /usr is so flat, and makes it impossible to put them on another partition. Maybe /usr/packages would be a better place, to (a) keep it under /usr, and (b) be able to mount it in a different partition. Maybe a structure like this... + usr + kde2.2 + kmail + konqueror + kde3 + bin + kmail - ../kde/kmail/bin/kmail ...or this... + usr + X11R6 + kde - kde2.2 + kde2.2 ...would help? Let's suppose /usr is mounted on a separate partition. Can you then mount /usr/kde2.2 to a separate partition as well if it seems to grow too big or do all mounted directories have to be in the root file system? - Jarno
Re: Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 07:22, Daniel Stone wrote: Now is a good time to follow wisdom of KDE hackers and install it in /opt/kde3 as we should. So that we don't have all of KDE cluttering the whole filesystem namespace (such as /usr/share/x) I don't want my frigging /opt namespace cluttered. I don't have anything there, but if we jump, EVERYONE will follow. We are not jumping. So be it. Then, review my suggestion for KDE3 that makes more sense for those who wouldn't like /opt. Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RtWGfAeuFodNU5wRAt8FAJ0baeI0Uw3Ko0YZlH6oXH8fB26WiwCfQlg0 a/sAd5bzP1GfIOmyhOST5uI= =FeSg -END PGP SIGNATURE-
Re: Interpreting FHS
On Thu, Jan 17, 2002 at 03:45:40PM +0200, Eray Ozkural (exa) wrote: On Thursday 17 January 2002 07:22, Daniel Stone wrote: Now is a good time to follow wisdom of KDE hackers and install it in /opt/kde3 as we should. So that we don't have all of KDE cluttering the whole filesystem namespace (such as /usr/share/x) I don't want my frigging /opt namespace cluttered. I don't have anything there, but if we jump, EVERYONE will follow. We are not jumping. So be it. Then, review my suggestion for KDE3 that makes more sense for those who wouldn't like /opt. In a word: shit. /usr/lib/kde3 is /opt under a different name. I don't want my $PATH cluttered, either. Nor do I want /usr/bin cluttered with symlinks, because that clutters up our namespace, eh? Back to square one! Leave it as is. -- Daniel Stone[EMAIL PROTECTED] luca aaronl, i have this site you should see... aaronl lemme guess, goatse.cx? luca how did you know! pgpC6uE8Cw2x4.pgp Description: PGP signature
Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 13:24, Daniel Stone wrote: I will not, under any circumstances, touch /opt. I believe Debian policy prohibits it anyway. I read the complete section for opt in the FHS. Here is my analysis. Using /opt for packages doesn't violate the policy in any way. I repeat, James *is* right. I suggest you to read it thoroughly before making further judgement. /opt is not intended solely for non-free add-on packages. It is provided for add-on packages of any sort. Here is the description /opt -- Add-on application software packages +-package Static package objects /opt is reserved for the installation of add-on application software packages. It turns out that add-on does not mean third party commercial vendor supplied in the following text of FHS. So indeed whoever interpreted it for Debian (somebody who is seriously unable to comprehend English) interpreted it incorrectly beforehand. It means what it says: application packages that can be installed/removed. Much like applications in debian. (which are not system software like libc) Here is a part that does interest debian: The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide front-end files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but shall function normally in the absence of these reserved directories. So those subdirs: /opt/bin, /opt/doc, /opt/include, /opt/infor, /opt/lib, /opt/man are forbidden. Don't touch those. You may do anything else you want with /opt in the manner described in detail in section 3.8 And the following excerpt I think clarifies the situation once and for all. Distributions may install software in /opt, but should not modify or delete software installed by the local system administrator without the assent of the local system administrator. : This means that Debian can install software in /opt except those subdirs listed above. Period. BEGIN RATIONALE The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [ATT 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here. : So this is not something invented by Red Hat or SuSe. The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt. Generally, all data required to support a package on a system should be present within /opt/package, including files intended to be copied into /etc/opt/package and /var/opt/package as well as reserved directories in /opt. : Most large application software packages are structured that way. The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software. END RATIONALE : The restrictions on subdirs of /opt are justified here. As I said, there is absolutely nothing in the FHS or Debian Policy that prohibits installing KDE in /opt. We need to interpret FHS correctly. KDE is an application package (a rather big one, though) and it would not be incorrect to install it in /opt as it is commonly done. Whoever thought policy did prohibit it must have interpreted FHS in a failing way; I assume they thought add on necessarily meant third party commercial vendor supplied whereas it does *not*. See the excerpt above to see what it says about distributions like red hat or debian. Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RYvMfAeuFodNU5wRAtXJAJ9y5MCpuEf4ZnmG+p9yqnV4b4hfqACdG0kI 92JzhUkBh0zm7ZN+rSsnTWs= =LcSJ -END PGP SIGNATURE-
Re: Interpreting FHS
On Wed, Jan 16, 2002 at 04:18:49PM +0200, Eray Ozkural (exa) wrote: Using /opt for packages doesn't violate the policy in any way. I repeat, James *is* right. I suggest you to read it thoroughly before making further judgement. Deciding to use it for KDE would, however, result in large numbers of admins becoming more than a little grumpy with you as they notice that you have decided to dump all of KDE onto their root filesystem. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpC3Y8t6xYqu.pgp Description: PGP signature
Re: Interpreting FHS
Am Mittwoch, 16. Januar 2002 15:18 schrieb Eray Ozkural (exa): As I said, there is absolutely nothing in the FHS or Debian Policy that prohibits installing KDE in /opt. We need to interpret FHS correctly. KDE is an application package (a rather big one, though) and it would not be incorrect to install it in /opt as it is commonly done. Whoever thought policy did prohibit it must have interpreted FHS in a failing way; I assume they thought add on necessarily meant third party commercial vendor supplied whereas it does *not*. See the excerpt above to see what it says about distributions like red hat or debian. But kde in /opt is sick. You cannot say: this app is an KDE2 app, so install it in /opt/kde2 This way, you do not look at packages which are somewhat KDE2 but not completely (e.g. licq). Then you probably say: it is only for main KDE. Well that does not make sense either. In my understanding: /opt is for packages that do not fit into the unix file system structure with the defined dirs like bin, lib, etc. What you now want to do with /opt is to make it to something like C:\programs on Windows systems. Does it make sense to have a unix structure defined when you do not want to integrate packages into it. If KDE cannot handle this then KDE has a serious problem there. You analyse FHS here what is not prohibited. But does it make sense to do it this way? No, because then _every_ package could do it this way (first KDE, the Gnome, then whatelse, where do _you_ draw the line?). HS
Re: Interpreting FHS
In my understanding: /opt is for packages that do not fit into the unix file system structure with the defined dirs like bin, lib, etc. What you now want to do with /opt is to make it to something like C:\programs on Windows systems. Just as a side note (NOT as a proposition by any means!): what's really so wrong in C:\program files style? Of course, on open systems, instead of vendor specific directories, there should be some other subdirectory policy (lsm for example?). If there were a way to remove symlinks when the original file is removed, I think the following structure would be the easiest to understand and administrate: + usr + bin + qtcups - ../qtcups/bin/qtcups + nano - ../nano/bin/nano + sbin + traceroute - ../traceroute/bin/traceroute + qtcups + etc (conf) + share (data) + bin (binaries) + doc (man, info) + nano + etc + bin + doc + traceroute + etc + bin + doc ...and even: + kde - kde2.2 + kde2.2 + kmail + konqueror + kde3 + bin + kmail - ../kde/kmail/bin/kmail ...or EVEN (a matter of policy again): + usr + X11R6 + kde - kde2.2 + kde2.2 ... Then, you could easily try different versions and remove whole packages manually without having to guess where their may have installed their binaries, libraries, configuration files, data, documents etc etc. Of course, this is pure fantasy since there are no 2-way links. If there were, however, this model could well be made reasonably backwards compatile. Does it make any sense? I.e. have I missed some important aspect of Unix here? - Jarno
Re: Interpreting FHS and KDE filesystem structure
On Wednesday 16 January 2002 12:09 pm, Allan Sandfeld Jensen wrote: On Wednesday 16 January 2002 12:27, Daniel Stone wrote: On Tue, Jan 15, 2002 at 08:55:16PM +, James Thorniley wrote: I'm supported also by Mosfet, see www.mosfet.org/fss.html for an actual argument for why directory layout should be more logical. You say that like it's a good thing. Mosfet's on drugs. Whether he's in this discussion or not, a personal attack is a flame, so not really relevant. It just happens that piece by Mosfet is well written. Although I cant see how putting kde in /opt/kde would be more logical.. If anywhere, I would put it in /usr/kde. Like X it is a system on its own, A system within the system. -Allan The reason I haven't been suggesting /usr/kde3 is it definitely would be against FHS. However I agree it would be better than /opt/kde3, especially if we take note of Mark Brown's argument (from Re: Interpreting FHS): Deciding to use it [/opt] for KDE would, however, result in large numbers of admins becoming more than a little grumpy with you as they notice that you have decided to dump all of KDE onto their root filesystem. I assume by this we mean people who have /usr on a seperate partition, which is an argument for using /usr/kde3, but that means getting FHS changed.. hmm, possible but difficult ;) Thanks, James
Re: Interpreting FHS
Am Donnerstag, 17. Januar 2002 01:48 schrieb Jarno Elonen: In my understanding: /opt is for packages that do not fit into the unix file system structure with the defined dirs like bin, lib, etc. What you now want to do with /opt is to make it to something like C:\programs on Windows systems. Just as a side note (NOT as a proposition by any means!): what's really so wrong in C:\program files style? Of course, on open systems, instead of vendor specific directories, there should be some other subdirectory policy (lsm for example?). The problem: where to install libs that come with the package and other might refer to? How to search for installed programs by looking at one direcory (without masses of symlinks)? How to have one nice dir for configuration files instead of searching, where there might be any? But dependent links would really be nice (ones that even follow when the file is copied) although practically hardly possible. HS
Re: Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 16:53, Hendrik Sattler wrote: But kde in /opt is sick. You cannot say: this app is an KDE2 app, so install it in /opt/kde2 This way, you do not look at packages which are somewhat KDE2 but not completely (e.g. licq). Then you probably say: it is only for main KDE. Well that does not make sense either. Tell this to kdecore hackers who designed it that way, and that way is being used by everybody else including unices other than linux. It's messed up just in debian. And may I add that KDE hackers loathe the debian packaging somehow? [*] There is some major misunderstanding there, some not-so-wise people somewhere decided that the common KDE installation applied in other distributions is not FHS compliant, althought it *is*, and now everybody and his dog thinks that /opt/kde3 violates FHS. It would be much more consistent if kde was just there in /opt/kde3. I don't say anything about KDE2, it's already obsolete. Trying to change KDE2 packaging would not be a good idea. Now is a good time to follow wisdom of KDE hackers and install it in /opt/kde3 as we should. So that we don't have all of KDE cluttering the whole filesystem namespace (such as /usr/share/x) Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RcWLfAeuFodNU5wRAir0AJ9GDvS1GPT3L6poYpCCqTliS3GGGACfW4oK U3W11zF92EiRxwyPJ8QJkYk= =Zpdy -END PGP SIGNATURE-
What's really missing ;) (WAS: Re: Interpreting FHS)
Hi, FWIW and only IMHO: I like that the layout used for KDE is the same as the rest of Debian. Nevertheless I agree that there is a 'big' problem with KDE in Debian KDE is configured to put config files to /etc/kde2 but KDE nevertheless uses /usr/share/config during runtime. There is something wrong in kdecore/kstddirs* or so. Fix this and then put into /etc/kde2/system.kdeglobals the dirs configure --prefix=/usr/local uses. This makes all sysadmin happy that are able to do handle the configure-make-make-install mantra. I guess that there's a similar way a user can manage a ~/my-kde tree but I never tried. Just my two ยค cents, Achim P.S. IMHO the I-want-to-switch-daily-between-kde2-and-kde3-and-mess-up -my-.kde-dir.-unfortunately-I-don't-understand-to-build-form-cvs users is the one that drives Debian maintainers crazy. I would never expect or some one spending his free time to take this on his shoulders and therefore I will never ask for it. Remember just IMHO ;) -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED]
Re: Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 20:25, Eray Ozkural (exa) wrote: up just in debian. And may I add that KDE hackers loathe the debian packaging somehow? [*] There is some major misunderstanding there, some [*] This is my impression from conversations on #kde. Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RetXfAeuFodNU5wRAnWFAJ4tdhYmO4H1ZaJ2DHG8UiOU+Nv4xACfYaX2 c9kIe8gIDeF7nr/dOX3xxa8= =sRak -END PGP SIGNATURE-
Re: Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 02:06 pm, Eray Ozkural (exa) wrote: On Wednesday 16 January 2002 20:25, Eray Ozkural (exa) wrote: up just in debian. And may I add that KDE hackers loathe the debian packaging somehow? [*] There is some major misunderstanding there, some [*] This is my impression from conversations on #kde. Before we get *too* far off on a tangent, from my long lurking on the kfm-devel and kmail mailing list, the problem isn't the packaging, as much as it is the *large* amount of bug reports filed by debian/testing users at bugs.kde.org when things break (like, for example, when kmail was out of sync with the rest of the packages and refused to work at all). Understandably, that bugs (heh) the hell out of them, and for a while they wouldn't even let debian users *submit* bug reports. However, afaik, that's all cleared up, with Ivan siding with them (if you have a problem with kde, file it with debian and Ivan (now D.Stone) will forward it on to the appropriate place, if needed). This has nothing to do with the location of the files on the drive, just how testing works. Anyways, that's all I had to say about that B-) - -- D.A.Bishop -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8Re0iEHLN/FXAbC0RAgPIAJ92LTB1c3GqTgWcQyG+zzAsu34xngCfbtwG ogb9ICkDeMhu7t1oNamRWAk= =kZUv -END PGP SIGNATURE-
Re: Interpreting FHS
On Wednesday 16 January 2002 12:20 pm, Jarno Elonen wrote: [snip] That said, FHS hardly is, if I have understood correctly, the optimal solution for anything but rather an educated tradeoff between usefulness and compatibility with existing UNIX systems. People generally present crique because they want things to improve, not because they want to prove that someone is imbecile. KDE indeed *is* a very large system and if many people feel that FHS or Debian policy are not up to date for desktop usage, those issues should be seriously discussed, IMHO. exactly. standards should be a contemporary method of enhancing interoperability, not some facist ethic that proscribes discussion of improvement. ben
Re: Interpreting FHS
On Thu, Jan 17, 2002 at 02:48:06AM +0200, Jarno Elonen wrote: -snip- If there were a way to remove symlinks when the original file is removed, I think the following structure would be the easiest to understand and administrate: + usr + bin + qtcups - ../qtcups/bin/qtcups + nano - ../nano/bin/nano + sbin + traceroute - ../traceroute/bin/traceroute + qtcups + etc (conf) + share (data) + bin (binaries) + doc (man, info) + nano + etc + bin + doc + traceroute + etc + bin + doc If it was structured like this then besides the other issues mentioned wrt libs, you could have up to ~ 8500 subdirs in /usr, not particularly good. 8) Chris Cheney
Re: Interpreting FHS
Call me crazy, but I've always thought that soft symlinks could be great here: - Put each package in it's own subdir under, say, /pkg. - Next, put symlinks into /usr/bin, /usr/lib, /etc, ad nauseum, in order to follow the Debian Policy. This way, you could have /pkg/qt2, /pkg/qt3, /pkg/kde2, etc... Maybe it's the DOS mentality of 1 subdir per program, but I think this makes things very organized. What's this about only 8500 sub-dirs in /usr? On Wed, 16 Jan 2002 19:22:09 -0600 Chris Cheney [EMAIL PROTECTED] wrote: On Thu, Jan 17, 2002 at 02:48:06AM +0200, Jarno Elonen wrote: -snip- If there were a way to remove symlinks when the original file is removed, I think the following structure would be the easiest to understand and administrate: + usr + bin + qtcups - ../qtcups/bin/qtcups + nano - ../nano/bin/nano + sbin + traceroute - ../traceroute/bin/traceroute + qtcups + etc (conf) + share (data) + bin (binaries) + doc (man, info) + nano + etc + bin + doc + traceroute + etc + bin + doc If it was structured like this then besides the other issues mentioned wrt libs, you could have up to ~ 8500 subdirs in /usr, not particularly good. 8) Chris Cheney -- ++ | Ron Johnson, Jr.Home: [EMAIL PROTECTED]| | Jefferson, LA USA http://ronandheather.dhs.org | || ! Millions of Chinese speak Chinese, and it's not | ! hereditary...| !Dr. Dean Edell ! ++
Re: Interpreting FHS
On Wed, Jan 16, 2002 at 07:40:26PM -0600, Ron Johnson wrote: Call me crazy, but I've always thought that soft symlinks could be great here: - Put each package in it's own subdir under, say, /pkg. - Next, put symlinks into /usr/bin, /usr/lib, /etc, ad nauseum, in order to follow the Debian Policy. This way, you could have /pkg/qt2, /pkg/qt3, /pkg/kde2, etc... Maybe it's the DOS mentality of 1 subdir per program, but I think this makes things very organized. What's this about only 8500 sub-dirs in /usr? The way he wrote the email/diagram he was putting each package under /usr/packagename. Chris
Re: Interpreting FHS
On Wed, Jan 16, 2002 at 04:18:49PM +0200, Eray Ozkural (exa) wrote: On Wednesday 16 January 2002 13:24, Daniel Stone wrote: I will not, under any circumstances, touch /opt. I believe Debian policy prohibits it anyway. I read the complete section for opt in the FHS. Here is my analysis. Did you also read Policy, or just the FHS? Using /opt for packages doesn't violate the policy in any way. I repeat, James *is* right. I suggest you to read it thoroughly before making further judgement. /opt is not intended solely for non-free add-on packages. It is provided for add-on packages of any sort. KDE is NOT an add-on! We provide it as part of Debian. My interpretation is add-on == third-party. Here is the description /opt -- Add-on application software packages +-package Static package objects /opt is reserved for the installation of add-on application software packages. It turns out that add-on does not mean third party commercial vendor supplied in the following text of FHS. So indeed whoever interpreted it for Debian (somebody who is seriously unable to comprehend English) interpreted it incorrectly beforehand. It means what it says: application packages that can be installed/removed. Much like applications in debian. (which are not system software like libc) How do you know that they didn't just omit third-party or such in that second sentence? Here is a part that does interest debian: The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide front-end files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but shall function normally in the absence of these reserved directories. So those subdirs: /opt/bin, /opt/doc, /opt/include, /opt/infor, /opt/lib, /opt/man are forbidden. Don't touch those. You may do anything else you want with /opt in the manner described in detail in section 3.8 I am not touching /opt in any way, shape or form. Period. And the following excerpt I think clarifies the situation once and for all. Distributions may install software in /opt, but should not modify or delete software installed by the local system administrator without the assent of the local system administrator. : This means that Debian can install software in /opt except those subdirs listed above. Period. Does Policy reinforce this? -- Daniel Stone[EMAIL PROTECTED] ultima netgod: My calculator has more registers than the x86, and -thats- sad pgpHTpehafeoy.pgp Description: PGP signature
Re: Interpreting FHS
On Wed, Jan 16, 2002 at 08:25:15PM +0200, Eray Ozkural (exa) wrote: On Wednesday 16 January 2002 16:53, Hendrik Sattler wrote: But kde in /opt is sick. You cannot say: this app is an KDE2 app, so install it in /opt/kde2 This way, you do not look at packages which are somewhat KDE2 but not completely (e.g. licq). Then you probably say: it is only for main KDE. Well that does not make sense either. Tell this to kdecore hackers who designed it that way, and that way is being Eray, get it through your head! KDE core hackers are NOT Debian packagers, they're upstream! If we did everything the upstream way, we'd have stuff like apache with its default setup in /usr/apache - thus, /usr/apache/bin, /usr/apache/lib, which is just braindamaged for a distribution to do - anyone will tell you that. Oh, wait, that's what you want for Debian. used by everybody else including unices other than linux. It's messed up just in debian. And may I add that KDE hackers loathe the debian packaging somehow? [*] There is some major misunderstanding there, some not-so-wise people somewhere decided that the common KDE installation applied in other distributions is not FHS compliant, althought it *is*, and now everybody and his dog thinks that /opt/kde3 violates FHS. It would be much more consistent if kde was just there in /opt/kde3. I don't say anything about KDE2, it's already obsolete. Trying to change KDE2 packaging would not be a good idea. Look, let me clear this up once and for all. Even if it doesn't violate the FHS, it's shithouse. We're setting a major precedent here. If you want to do this (not that you're even the maintainer), talk to -devel. Setting precedents is NOT -kde's decision. Now is a good time to follow wisdom of KDE hackers and install it in /opt/kde3 as we should. So that we don't have all of KDE cluttering the whole filesystem namespace (such as /usr/share/x) I don't want my frigging /opt namespace cluttered. I don't have anything there, but if we jump, EVERYONE will follow. We are not jumping. -- Daniel Stone[EMAIL PROTECTED] sel need help: my first packet to my provider gets lost :-( netgod sel: dont send the first one, start with #2 pgpwKkJBGBbCU.pgp Description: PGP signature
