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/) 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]> need help: my first packet to my provider gets lost :-( sel: dont send the first one, start with #2 pgpwKkJBGBbCU.pgp Description: PGP signature
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 >+- 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]> netgod: My calculator has more registers than the x86, and -thats- sad pgpHTpehafeoy.pgp Description: PGP signature
Re: KDE filesystem structure
On Wed, Jan 16, 2002 at 03:39:26PM +0200, Eray Ozkural (exa) wrote: > On Wednesday 16 January 2002 14:09, Allan Sandfeld Jensen wrote: > > > > > > You say that like it's a good thing. Mosfet's on drugs. > > > > 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". > > We call that a "subsystem" in engineering. Heh :) > > Generally speaking, it's good design if a system can have physical modularity > to some extent, ie logical modularity is evident in the case of X11 but > physical modularity makes it more sensible to deal with. > > Therefore, a system that uses an efficient unified filesystem implementation > instead of a packaging system to keep track of file locations would be much > more consistent than Debian.[*] I'm hoping to see something like that with > the use of more advanced kernels. > > Thanks, > > [*] So every package looks like X11. Packaging system's responsibility is > making sure that the system is consistent and in a working state rather than > showing you which file is stored where... export PATH=$PATH:/opt/kde/bin:/opt/kde3/kin:/opt/qt/bin:/opt/apache/bin:/opt/apache2/bin:/opt/koffice/bin:/opt/gcc/bin:... NO. -- Daniel Stone<[EMAIL PROTECTED]> my sister's getting married she's still in el paso your borther must be a very happy man pgp48mFHFYUr8.pgp Description: PGP signature
Re: KDE filesystem structure
On Wed, Jan 16, 2002 at 03:17:38PM +, James Thorniley wrote: > On Wednesday 16 January 2002 4:44 am, Jaldhar H. Vyas wrote: > > [Eray Ozkural wrote:] > > > that's why many RPM's have files in /opt. > > > > Ha! RPMs tend to spew files all over the place. Hardly relevant. > > > ... > > > However, your quote does imply that redhat, suse, etc. packaging which > > > installs in /opt/kde3 is indeed FHS compliant. I wonder who was clueless > > > enough to think otherwise upon reading FHS. > > > > I for one. And SuSe Red Hat have never impressed me with their adherence > > to standards. > > > > The fact of the matter is that SuSE and Redhat produce distributions where I honestly do not care what SuSE and RedHat do. We are not SuSE and RedHat, we're Debian. It's hard to express my next sentence without trolling, so I won't say it, but I'm sure you know what it is. -- Daniel Stone<[EMAIL PROTECTED]> *mhp* I can't get myself to delete mail. it's like murdering someone pgpKRw6RjuQ1o.pgp Description: PGP signature
Re: Interpreting FHS
On Wed, 16 Jan 2002 20:05:00 -0600 Chris Cheney <[EMAIL PROTECTED]> wrote: > 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. 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. -- ++ | 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
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: KDE filesystem structure
On Wed, Jan 16, 2002 at 04:55:17PM +0100, Hendrik Naumann wrote: -snip- > - From an sysadmin point of view it is realy nice to have MOST of the > programms and the mayority of diskspace under /usr. I think many > networks are planed that way. Shure one could just link /opt to > /usr/opt and everything work, but then lets just start with > /usr/opt. I don't know if this is the case on all commerical *nix but /opt is typically bigger than /usr on them, and on the machines I admin is much larger. So I guess the many networks planned that way (large /usr) are all Linux networks? /usr/opt isn't defined in FHS so would probably not be a good idea. Chris
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:51:44PM +, Julian Gilbey wrote: -snip- > > * Some proposed using /opt/kde3. Arguments: > > Not as a Debian package. /opt is for third-party software. > >Julian perhaps you should have read the rest of the email from him... :)
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: KDE filesystem structure
On Thu, Jan 17, 2002 at 08:55:02AM +1100, Daniel Stone wrote: > the Dark Ages. When you ask people what the best thing about Debian is, > they respond "policy" (in general; some say dpkg/apt). So what are we > doing? Random crap, I hear you say? Not to mention the fact that one of the major reasons apt and dpkg get to rock so hard is that they have a nice, consistent set of packages to work with. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpYKMVEgvk1e.pgp Description: PGP signature
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:19:25PM +0200, Jarno Elonen wrote: > Hi, > > May I try to summarize the filesystem discussion on KDE list and suggest that > it will continue in debian-policy? > > * Many people feel that KDE (and Gnome) is too large >a whole to be stuffed in /usr/bin, /usr/share etc >and would deserve a separate directory like X Interesting. > * Some proposed using /opt/kde3. Arguments: Not as a Debian package. /opt is for third-party software. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Debian GNU/Linux Developer Queen Mary, Univ. of London see http://people.debian.org/~jdg/ http://www.maths.qmul.ac.uk/~jdg/ or http://www.debian.org/ Visit http://www.thehungersite.com/ to help feed the hungry
What are Chris and Daniel actually going to do now?
On Fri Dec 14, 2001 Ivan E. Moore II wrote: > With kde3 my current (and yet truely tested) approach for file layout is > pretty much everything under /usr/share/kde /usr/lib/kde > (and /usr/lib/kde3 for the modules) /etc/kde. Any chance that Chris and Daniel will hold to that? -- Oliver Johns <[EMAIL PROTECTED]> San Francisco, California USA GPG KeyID=A2ACE692 GPG Fingerprint=BE4A C1B8 EB0D 8FD9 737D CE4A 1E56 BF9B A2AC E692
Re: KDE filesystem structure
On Wed, Jan 16, 2002 at 03:31:07PM +0200, Eray Ozkural (exa) wrote: > On Wednesday 16 January 2002 13:29, Daniel Stone wrote: > > > Note that *everybody* except debian uses /opt/kde3, and changing to that > > > would be beneficial. The current layout has to be changed in any case, it > > > is major brain damage. > > > > Changing the way Debian has packaged stuff for KDE3 and surprising the > > hell out of everyone is an astoundingly bad move. Don't do it. > > > > Why is Debian majorly brain-damaged in this regard? Policy of least > > surprise, because I think you'll find quite a few people surprised when > > we RANDOMLY CHANGE LOCATIONS ON A WHIM. > > Well the directory layout simply doesn't make sense. It's possible to be both > policy compliant and obey KDE conventions. Using /usr/lib/kde3 as KDE root > mainly. See my other mail to see how it would be done. This would remove a > lot of cruft from debian packaging scripts as well so it really is a good > thing. There are *very*, *VERY*, few times when I'm inclined to quote Jared Johnson (solomon), but this is one of them: bzt bzzzt! hear that it is the big buzzer that means you are wrong wrong wrong! still going off A BZT IT IS GETTING LOUD AND LOUDER SIGNIFYING THE PROFOUND WRONGNESS OF YOU BUAAR!!! Using that as the KDE root is just SILLY BAD WRONG EVIL. Do you also advocate having the apache root in /usr/lib/apache? After a while it starts to defeat the whole point of /usr/bin. What next? A Debconf note saying that you have to have "export PATH=$PATH:/usr/lib/kde3/bin" in your ~/. to be able to run startkde? > Add that the fact that KDE3 is not even properly packaged now: there is room > for improvement on that front. I'd though like to hear Chris's opinion first > as he is the person dealing with these issues. I'm still "prohibitively" busy > to engage in any hacking activity :/ KDE3 will be properly packaged the moment it can be installed side-by-side with KDE2.2 using *standard* *Debian* *layouts*. Let policy dictate what we do, not lines of crack. > Otherwise, only packagers and programmers care about KDE locations. The above > change would make both happier. Not to forget your average punter who doesn't want to type /usr/lib/kde3/bin/startkde, every time. > 1) Packagers can have very trivial build scripts, I can even provide a > Makefile to be included in admin/ dir. (And remove that redundant perl script > that dumps a text file BTW) > 2) Programmers can easily test their applications on a debian system by > compiling to prefix /usr/lib/kde3. Daniel's Amazing Fantastic Fabulous Mind-Rocking Guide To Building A KDE App On Debian: ./configure --prefix=/usr make su -c 'make install' > These are benefits not to be ignored. I say we go ahead and do a major > cleanup, it's not that difficult btw we are just going to change a few > makefiles that's all, and write a small text file telling people how they > should make debian KDE3 packages. I think an example kde-hello package might > make sense. I register my vote of disgust. It IS difficult, in fact, because it means we fuck around with how Debian has done things since well before the Dark Ages. When you ask people what the best thing about Debian is, they respond "policy" (in general; some say dpkg/apt). So what are we doing? Random crap, I hear you say? Don't. Please. -- Daniel Stone<[EMAIL PROTECTED]> * Culus fears perl - the language with optional errors pgpSWodtTdkPd.pgp Description: 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
Summary of KDE filesystem discussion
Hi, May I try to summarize the filesystem discussion on KDE list and suggest that it will continue in debian-policy? * Many people feel that KDE (and Gnome) is too large a whole to be stuffed in /usr/bin, /usr/share etc and would deserve a separate directory like X * Some proposed using /opt/kde3. Arguments: + Other distributions work like this, and better compatibility with them could be beneficial + FSH seems to permit this (possible misunderstandings about phrase 'add-on package' in it)... - ...but Debian policy apparently does not. - /usr is deliberately placed on another (large) partition on many computers and changing KDE to /opt could ruin this optimization - Changing from /usr to /opt could surprise and confuse seasoned Debian users who remember the policy in their dreams.. * Classifying applications to KDE and just "generic Qt" apps could be difficult and so deciding if something should go under KDE-dir or some else could be difficult * The debate got quite emotional (which seemingly often happens when discussing the policy?-) - Jarno -- Learn Finnish! "Epäjärjestelmällistyttämättömyydellisyydellänsäkäänköhän?" = "Not even with his or her own ability or property of not making other people to make things unorganized, I wonder?"
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
-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
On Wednesday 16. Januaryta 2002 20:27, Eray Ozkural (exa) wrote: > On Wednesday 16 January 2002 17:41, Hendrik Sattler wrote: > > 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? > > These issues are already addressed by FHS. Read it. The people who wrote it > are not imbecile. > > Grow some trust in a practice that's being repeated for more than a decade > in other UNIX systems. His (very constructive) critique was aimed at *my* possibly imbecile idea of reorganizing the file system, not at FHS. 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. - Jarno
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: KDE filesystem structure
On Wednesday 16 January 2002 03:43 am, Daniel Stone wrote: > On Wed, Jan 16, 2002 at 01:35:33PM +0200, Jarno Elonen wrote: > > On Wednesday 16. Januaryta 2002 13: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. > > > > No need to get personal, thank you. I personally like some of the guy's > > work and think his opinions deserve some respect, too. > > What he does is good, even if I do think that Aqua's crap, but I think > that he's on drugs for reasons that are too off-topic to go into here, > and I can't be stuffed elaborating them at all when I'm writing this > over lagged SSH. > > What he does is good, but that doesn't mean that he's not on drugs. if the reasons for your statement are too off-topic to go into, then the statement is inappropriately made in this forum, as well as being unsupported slanderous innuendo that should be retracted.
Re: KDE filesystem structure
On Wed, 16 Jan 2002, James Thorniley wrote: > The fact of the matter is that SuSE and Redhat produce distributions where > their installation of KDE is compatible with an installation from source of > KDE from ftp.kde.org. A default installation of Apache from source installs into /usr/local/etc. Should Debian try and be compatible with that? The whole reason you are using a distro and not, say, Linux From Scratch, is to get an integrated system that works consistently. > In debian, for some reason, all the docs have been > moved from [kde-prefix]/share/doc/HTML// to > [kde-prefix]/share/doc/kde/HTML//. This makes it > virtually impossible to produce a source distribution of a KDE app which is > compatible with all GNU/Linux distributions (unless you're in the mood for > messing about with the hell-on-earth that is automake macros, not to mention > I don't see why I should have to deviate from the standard automake macros > provided by KDE, since they work for every other distribution). apt-get install autobook. It should teach you everything you need to know about how automake etc. work. In particular the "impossible" feat you mentioned is very easy to resolve; Do: export kde_htmldir=/usr/share/doc/kde/HTML before running configure. In fact that's precisely the kind of things the Debian packages do. You could argue that is kind of thing isn't very well documented and you would have a point but a point in a different debate than this one. :-) > > Oh and btw, /usr/X11R6 and /usr/games were both UNIX traditions from > > before Linux and were grandfathered in to the FHS. They really shouldn't > > exist. > > Interesting you note this, since this kind of logical directory layout is of > course the traditional UNIX way. Yes and this is why my Solaris box has binaries under /usr/apache, /usr/ccs /usr/dt, /usr/dict, /usr/java1.1, /usr/java1.2 /usr/openwin, /usr/perl5, /usr/xpg4, and /usr/ucb and my $PATH is half a mile long. I don't see how an ever-growing list of directories makes things any easier for the user or the admin in the long run. We have modern packaging systems like rpm or deb. We don't need to rely on the admins overtaxed brain to keep track of things. > The FHS rather goes against traditional UNIX > thinking that most old sysadmins are happy with (see the Mosfet artical > again. www.mosfet.org/fss.html). I also happen to think that the consensus > from all other GNU/Linux distributions does add some weight - whether it's > truly standards compliant, they've all thought about it as a team of > developers and have come up with the same answer, and they're not stupid. > Actually all the major distros have agreed at least in prncipal to the FHS (as part of the Linux Standard Base or from before.) So it is just a matter of when they start complying not if. I know Red Hat 7.2 for example doesn't install anything into /opt. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> It's a girl! See the pictures - http://www.braincells.com/shailaja/
Re: KDE filesystem structure
On Wed, 16 Jan 2002, Eray Ozkural (exa) wrote: > It seems that your reasoning that "/opt is reserved for things like Loki > games" is incorrect. See my mail titled "Interpeting FHS". > [...] > > That is a serious misunderstanding of "add-on". By add-on here it means > application software that is not essential for system functionality, such as > KDE. Saying that "distribution provided" software is not "add on application > software" is gross misunderstanding of the terms involved. Yes I saw it but you are still missing the point. English is not the most precise of languages but the meaning of add-on should be fairly clear. It is something extra beyond what is provided in the base distribution. So how would you define that for Debian? contrib and non-free which are not officially part of Debian? Any package of priority optional or extra? As you can see none of those packages are placed in /opt. The use of /opt goes back to the bad old days of commercial UNIX when vendors would try and soak you for every penny you had. (I believe with SCO even TCP/IP was an add-on at one point!) You would have a base OS and other extra packages you could purchase. Also third-party vendors would sell their own packages. Plus there was free software. All of those things were usually placed in /opt to signify they were not part of the base OS. For instance on a Solaris 8 system I have here there are only three things under /opt. /opt/gnome-1.4 is GNOME, not a Sun product. /opt/sfw comes from a CD of freeware they put out which again is not a Sun product and /opt/SUNWebnfs is WebNFS which is a Sun product but not part of basic Solaris. Now how do you map this concept of addons to Debian? All our packages, even the "extra" and "non-free" ones are first-class citizens. We don't sell enhancements or upgrades. Conceivably in the days of the licensing wars you could have considered KDE an "add-on" to Debian but not now. > > On the contrary, FHS says distributions can install software in /opt, except > certain subdirs reserved for the system administrator. > Does SuSe consider KDE3 to be a "preview" release or unsupported or sometheing you pay extra for? Then it would be legitimate to put it into /opt. If they are just too lazy to properly integrate it into their system then this is not something we should be emulating. > Before you give an answer to this, please read the mail I mentioned, and > section 3.8 in complete. > Also bear in mind the purpose of the FHS is not just to set policy but codify existing practice. Somethings may be allowed which are not necessarily recommended to do. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> It's a girl! See the pictures - http://www.braincells.com/shailaja/
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 23:52, Jens Benecke wrote: > > Yes. But using subdirs is required when there are too many files rather > > than the total size of files exceeding a threshold. > > Yes, and as soon as you define what "too many" is, those are identical. Eh. Still there is the case of a small software package with several files and directories. Most of my own programs are like that I believe. 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 iD8DBQE8RcZHfAeuFodNU5wRArslAKCar3QUM5b2AUPww2PoWRF1jCnOngCffXRY xizX4xICSoT1Kr4KAZNskZI= =V3n5 -END PGP SIGNATURE-
Re: Interpreting FHS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 17:41, Hendrik Sattler wrote: > > 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? > These issues are already addressed by FHS. Read it. The people who wrote it are not imbecile. Grow some trust in a practice that's being repeated for more than a decade in other UNIX systems. 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 iD8DBQE8RcYGfAeuFodNU5wRAnqAAJ9owwMsaV7BFIOpB/ROK24BSQtl9gCeNXxc TiXfpulI7cbRTszqDZcvtCY= =RycF -END PGP SIGNATURE-
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/) 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-
Re: Interpreting FHS
> > 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? For libraries: my proposition was exactly "masses of (dependent) symlinks". For other files: if you know the name of the package you want to configure (which usually is the case), you would look in /usr//etc. > But dependent links would really be nice (ones that even follow when the file > is copied) although practically hardly possible. I think they could be pretty effectively implemented if filesystem development goes into direction that ReiserFS advocates are planning. You would simply have a flag in an inode, telling that others rely on it, and once it is deleted (or moved), a "symlink fat query" would be performed. But well, once again, this is probably going to far out of the topic (KDE on Debian)... - Jarno
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi > > If KDE is packaged for Debian by Debian developers it is not an > >addon and _does_not_ belong in /opt. > > That is a serious misunderstanding of "add-on". By add-on here it > means application software that is not essential for system > functionality, such as KDE. Saying that "distribution provided" > software is not "add on application software" is gross > misunderstanding of the terms involved. I don't share your interpretation of "add-on". But I don't want to continue argueing about FHS and it interpretation. - From an sysadmin point of view it is realy nice to have MOST of the programms and the mayority of diskspace under /usr. I think many networks are planed that way. Shure one could just link /opt to /usr/opt and everything work, but then lets just start with /usr/opt. I also wouldn't mind /usr/kde /usr/gnome ... if that makes live easier for developers and package maintainers. It think /usr/games is sensless, but /usr/X11R6 is good to be there. Just my 2 cents Hendrik - -- PGP ID 21F0AC0265C92061 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RaJmIfCsAmXJIGERAh7EAJ99VZsBAUa0rRAiXUUM/ziRszFOpwCeJAjG x3eX6ShchBrtI04/IiiWkzE= =20py -END PGP SIGNATURE-
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 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
> 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: KDE filesystem structure
On Wednesday 16 January 2002 4:44 am, Jaldhar H. Vyas wrote: > [Eray Ozkural wrote:] > > that's why many RPM's have files in /opt. > > Ha! RPMs tend to spew files all over the place. Hardly relevant. > ... > > However, your quote does imply that redhat, suse, etc. packaging which > > installs in /opt/kde3 is indeed FHS compliant. I wonder who was clueless > > enough to think otherwise upon reading FHS. > > I for one. And SuSe Red Hat have never impressed me with their adherence > to standards. > The fact of the matter is that SuSE and Redhat produce distributions where their installation of KDE is compatible with an installation from source of KDE from ftp.kde.org. In debian, for some reason, all the docs have been moved from [kde-prefix]/share/doc/HTML// to [kde-prefix]/share/doc/kde/HTML//. This makes it virtually impossible to produce a source distribution of a KDE app which is compatible with all GNU/Linux distributions (unless you're in the mood for messing about with the hell-on-earth that is automake macros, not to mention I don't see why I should have to deviate from the standard automake macros provided by KDE, since they work for every other distribution). In fact, once I work out who is maintaining KDE3, that's all I will be asking them to do - mimic that standard kde directory layout under the prefix of their choice - I don't mind if it's still in /usr (it's just not ideal to me). If I was the maintainer, I would move it, but I'm not going to ask someone else to put up with the flames and the bug reports. > Oh and btw, /usr/X11R6 and /usr/games were both UNIX traditions from > before Linux and were grandfathered in to the FHS. They really shouldn't > exist. Interesting you note this, since this kind of logical directory layout is of course the traditional UNIX way. The FHS rather goes against traditional UNIX thinking that most old sysadmins are happy with (see the Mosfet artical again. www.mosfet.org/fss.html). I also happen to think that the consensus from all other GNU/Linux distributions does add some weight - whether it's truly standards compliant, they've all thought about it as a team of developers and have come up with the same answer, and they're not stupid. Yours, James
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
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: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jadhar, It seems that your reasoning that "/opt is reserved for things like Loki games" is incorrect. See my mail titled "Interpeting FHS". I recommend you to re-read the relevant section of FHS without resorting to certain preconceptions such as "In Debian /opt is not used". It is written in a plain and clear English that says no such thing as you say. > If KDE is packaged for Debian by Debian developers it is not an >addon and _does_not_ belong in /opt. That is a serious misunderstanding of "add-on". By add-on here it means application software that is not essential for system functionality, such as KDE. Saying that "distribution provided" software is not "add on application software" is gross misunderstanding of the terms involved. On the contrary, FHS says distributions can install software in /opt, except certain subdirs reserved for the system administrator. Before you give an answer to this, please read the mail I mentioned, and section 3.8 in complete. 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 iD8DBQE8RY2kfAeuFodNU5wRAqg8AJ43K1aSMgRkzxDdU1t3cQqOJYkwHwCeJLWf rCeRcotCSCjQpDbGOuhXSbw= =4WSR -END 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 +- 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 [AT&T 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/, including files intended to be copied into /etc/opt/ and /var/opt/ 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: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 14:09, Allan Sandfeld Jensen wrote: > > > > You say that like it's a good thing. Mosfet's on drugs. > > 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". We call that a "subsystem" in engineering. Heh :) Generally speaking, it's good design if a system can have physical modularity to some extent, ie logical modularity is evident in the case of X11 but physical modularity makes it more sensible to deal with. Therefore, a system that uses an efficient unified filesystem implementation instead of a packaging system to keep track of file locations would be much more consistent than Debian.[*] I'm hoping to see something like that with the use of more advanced kernels. Thanks, [*] So every package looks like X11. Packaging system's responsibility is making sure that the system is consistent and in a working state rather than showing you which file is stored where... - -- 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 iD8DBQE8RYKOfAeuFodNU5wRArKQAJ0TncDURKAnufkozdICQNnHEeNSawCgnS1t tnZXm1WY6HYRmwWK0DN37hQ= =K1a3 -END PGP SIGNATURE-
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 13:32, Daniel Stone wrote: > > Type mismatch here. You were talking about /usr, not /usr/share. Please > > ignore that earlier comment. > > Lucky, because my next reply was "Show me a serious bug on all KDE apps > and I will wring your neck". Heh, my previous mail can only be attributed to cheap drugs. 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 iD8DBQE8RYDIfAeuFodNU5wRAtGyAKCJTjgVkJ1jg2S1kSCpzHMNWWAkigCfc1X/ Jj2y4bESy2LC/6WHs0ZSHbI= =K3tp -END PGP SIGNATURE-
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 13:29, Daniel Stone wrote: > > Note that *everybody* except debian uses /opt/kde3, and changing to that > > would be beneficial. The current layout has to be changed in any case, it > > is major brain damage. > > Changing the way Debian has packaged stuff for KDE3 and surprising the > hell out of everyone is an astoundingly bad move. Don't do it. > > Why is Debian majorly brain-damaged in this regard? Policy of least > surprise, because I think you'll find quite a few people surprised when > we RANDOMLY CHANGE LOCATIONS ON A WHIM. Well the directory layout simply doesn't make sense. It's possible to be both policy compliant and obey KDE conventions. Using /usr/lib/kde3 as KDE root mainly. See my other mail to see how it would be done. This would remove a lot of cruft from debian packaging scripts as well so it really is a good thing. Add that the fact that KDE3 is not even properly packaged now: there is room for improvement on that front. I'd though like to hear Chris's opinion first as he is the person dealing with these issues. I'm still "prohibitively" busy to engage in any hacking activity :/ Otherwise, only packagers and programmers care about KDE locations. The above change would make both happier. 1) Packagers can have very trivial build scripts, I can even provide a Makefile to be included in admin/ dir. (And remove that redundant perl script that dumps a text file BTW) 2) Programmers can easily test their applications on a debian system by compiling to prefix /usr/lib/kde3. These are benefits not to be ignored. I say we go ahead and do a major cleanup, it's not that difficult btw we are just going to change a few makefiles that's all, and write a small text file telling people how they should make debian KDE3 packages. I think an example kde-hello package might make sense. 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 iD8DBQE8RYCdfAeuFodNU5wRAj6JAJ9ktrYg+7qcqFUeTNsRbvU3mN8I2QCeNak5 mf4GaSELQo8/Wqb7BypGLkI= =z46G -END PGP SIGNATURE-
Re: KDE filesystem structure
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. 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
Re: KDE filesystem structure
> > > > 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. > > > > No need to get personal, thank you. I personally like some of the guy's > > work > > and think his opinions deserve some respect, too. > > What he does is good, even if I do think that Aqua's crap, but I think > that he's on drugs for reasons that are too off-topic to go into here, > and I can't be stuffed elaborating them at all when I'm writing this > over lagged SSH. > > What he does is good, but that doesn't mean that he's not on drugs. Even *if* that was true, it is, IMHO, a) his very own business and b) not something that one speculate about on a mailing list - especially "debian-kde". As a popular email tagline tells us: "No violence, gentlemen, I beg you! Consider the furniture! - Sherlock Holmes" - Jarno
Re: KDE filesystem structure
On Wed, Jan 16, 2002 at 01:35:33PM +0200, Jarno Elonen wrote: > On Wednesday 16. Januaryta 2002 13: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. > > No need to get personal, thank you. I personally like some of the guy's work > and think his opinions deserve some respect, too. What he does is good, even if I do think that Aqua's crap, but I think that he's on drugs for reasons that are too off-topic to go into here, and I can't be stuffed elaborating them at all when I'm writing this over lagged SSH. What he does is good, but that doesn't mean that he's not on drugs. -- Daniel Stone<[EMAIL PROTECTED]> * wiggy points people to arcanum.co.nz apparently it's fun wiggy: the last time you said that we lost an entire weekend of useful activity to cocklefighting pgpI3EB2YMuDK.pgp Description: PGP signature
Re: KDE filesystem structure
On Wednesday 16. Januaryta 2002 13: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. No need to get personal, thank you. I personally like some of the guy's work and think his opinions deserve some respect, too. - Jarno
Re: KDE filesystem structure
On Wed, Jan 16, 2002 at 08:04:30AM +0200, Eray Ozkural (exa) wrote: > On Tuesday 15 January 2002 22:59, Eray Ozkural (exa) wrote: > > > > So /usr/share/apps violates FHS policy? That does not seem to be the case > > IIRC. Show me the policy in FHS and I will submit a serious bug to all KDE > > packages. > > Type mismatch here. You were talking about /usr, not /usr/share. Please > ignore that earlier comment. Lucky, because my next reply was "Show me a serious bug on all KDE apps and I will wring your neck". -- Daniel Stone<[EMAIL PROTECTED]> it's not ALL: PARANOID, it's FUCKING: BROKEN pgpz6LgSE0GW0.pgp Description: PGP signature
Re: KDE filesystem structure
On Tue, Jan 15, 2002 at 11:22:13PM +0200, Eray Ozkural (exa) wrote: > However, your quote does imply that redhat, suse, etc. packaging which > installs in /opt/kde3 is indeed FHS compliant. I wonder who was clueless > enough to think otherwise upon reading FHS. Daniel and Chris could you please > examine James' argument, it does seem to be valid. Oh yes, RedHat and SuSE do it that way, so it MUST be right! Clearly!! > Note that *everybody* except debian uses /opt/kde3, and changing to that > would be beneficial. The current layout has to be changed in any case, it is > major brain damage. Changing the way Debian has packaged stuff for KDE3 and surprising the hell out of everyone is an astoundingly bad move. Don't do it. Why is Debian majorly brain-damaged in this regard? Policy of least surprise, because I think you'll find quite a few people surprised when we RANDOMLY CHANGE LOCATIONS ON A WHIM. -- Daniel Stone<[EMAIL PROTECTED]> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. pgpJavkHrle7Y.pgp Description: PGP signature
Re: KDE filesystem structure
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. -- Daniel Stone<[EMAIL PROTECTED]> yip yip yip yip yip yip yap yap yip *BANG* NO TERRIER -- Michael Beattie's .signature pgpsSxd1315S6.pgp Description: PGP signature
Re: KDE filesystem structure
On Tue, Jan 15, 2002 at 11:58:08AM -0800, Oliver Johns wrote: > The Debian policy is violated, in principle anyhow, > by the whole X-windows system. It DOES have its own special > subdirectories. The reason is that it is so large and > complicated that good sense demands putting it in a special > place to make it easier to keep track of it. The real question > is whether kde and gnome have now reached that status. I think > they have. For one thing, people who use both kde and gnome > experience trouble knowing which app or which library or shared > file belongs to which. It would be VERY helpful, and quite > rational, for Debian to follow, or even one-up, the other dists > and treat BOTH of those two mega-systems specially. I will not, under any circumstances, touch /opt. I believe Debian policy prohibits it anyway. -- Daniel Stone<[EMAIL PROTECTED]> net: No, it's more if you have an infinite number of monkeys and an infinite number of hard drives, one of them will eventually make a distro, package it up and go an IPO. pgpwDyvnhXOge.pgp Description: PGP signature
Re: kde not starting as normal user
On Wednesday 16 January 2002 00:40, Jens Benecke wrote: > Hey. Where do I get this? A friend of mine has a Compaq laptop (Presario > 700) and it's all ACPI, no APM. When I press the "powersave" button the > laptop locks up hard. Of course apmd doesn't work. $ apt-cache search acpid - whoa :) But you must compile your own kernel with acpi (with 'button' feature enabled). The default install of acpid executes the 'shutdown' command if you press the power button. Very cool, but I use my remote control for this anyway :-) -- Akos
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 22:59, Eray Ozkural (exa) wrote: > > So /usr/share/apps violates FHS policy? That does not seem to be the case > IIRC. Show me the policy in FHS and I will submit a serious bug to all KDE > packages. Type mismatch here. You were talking about /usr, not /usr/share. Please ignore that earlier comment. 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 iD8DBQE8RRfufAeuFodNU5wRAtjtAJ0REf4iIQivh0v8H+e0xHKoTPJhBgCgoSdN jwLh78InjZbPFJrBQzqEyXs= =OFqW -END PGP SIGNATURE-
Re: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 15 January 2002 23:05, Eray Ozkural (exa) wrote: > > Why would a package having its own special subdirectories violate Debian > Policy? That is very common practice and it's a good thing for even small > codes. What exactly do you mean? Show me the section please. > You mean any subdirectory in a directory not allowed in Debian Policy of course, such as / or /usr. 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 iD8DBQE8RReQfAeuFodNU5wRArbCAKCWK7U8GZVFzVCMLqaRyJxN/Pfc1gCfQyqF uDyE11RRBPPJYraKVA2uOJ0= =q5B7 -END PGP SIGNATURE-
