Re: [kde] setting an /opt precedent
On Fri, 18 Jan 2002, Eray Ozkural (exa) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Jamie, > > As I wrote to Jeff, it would be best to explain in Debian Policy why debian > packages should not install files in /opt, with preferably a short sentence > clarifying that it is practically impossible to assure administrator's assent > (that is in our interpretation). Debian policy should not itemize all the reasons for doing or not doing something. Common sense needs to be applied.
Anti Aliased fonts in SID?
I was just curious to weather anti aliased fonts are included in SID's kde 2.2.2.? I was reading the lists approximately 1-2 weeks ago and I noticed DanielS say that he wasnt going to include the packages due to their instability. Anyway my SID box hasn't been updated for about one month and to be perfectly honest my KDE is working sensationally with anti aliased fonts. So I am really just sending this message in a precautionary effort for myself ; ) oh and keep up the good work DanielS no complaints from me whatsoever.
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jamie, As I wrote to Jeff, it would be best to explain in Debian Policy why debian packages should not install files in /opt, with preferably a short sentence clarifying that it is practically impossible to assure administrator's assent (that is in our interpretation). I am not obsessed with installing files in /opt, it was an idea offered by one of the users in debian-kde and it looked plausible at that time. Neither am I trying to set a precedent, as Chris is responsible for KDE packages not me. I am going to help lower his load; I had volunteered for kdemultimedia a long time ago since I am developing for kde multimedia player... 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 iD8DBQE8R31xfAeuFodNU5wRArzhAJ4v9zs9kxjYy8YJ7G4yZFfpx/Sl3ACdH1XE hDUOjw6EBV/Qin20VGd6Vgs= =xEnr -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
This one time, at band camp, Eray Ozkural (exa) wrote: >So, what are the "reasons behind Debian not mucking about with /opt" except >the preconceptions of some developers? I think you would have to say >something like: > >* It is not very consistent with the directory layout many packages adapt > >Is there any other reason? I assume none, since front end files can be placed >by the distribution in usual locations by symlinking or by wrapper scripts. > >There is an _invalid_ reason which I had to iterate over and over again: > * /opt is reserved for system administrator's use. Eray, As you have already pointed out, you *cannot* overwrite files in /opt without the assent (and perhaps to be safe, the *explicit* assent) of the sysadmin. So, you will want some way to check that the directory /opt/kde isn't already in use, and then divert to another directory, keep iterating until you find one that's free. This of course makes it difficult when you're upgrading your own package, you'll have to keep a record of where you installed to. Then as others have pointed out, you need to make the binaries available immediately to the user. You can't use $PATH, you can't symlink to other locations in /opt, and for the sake of cleanliness, you can't really symlink to /usr/bin, etc. Your time starts now. I think you're just making more work for yourself, regardless of the technical merits of not installing to /opt -- and by setting a precendent, you're making more work for everyone else. >NO! Certain subdirectories of /opt are reserved for local system admin. The >rest of /opt can be used by the distribution, as explained in FHS with a >language that a high school student can easily understand. You can't make that assumption... what if the admin wants to *later* install a vendor package into /opt which isn't as amazingly flexible as your package, and it overwrites your installed directory? Then you've got package management problems too. The rule of least surprise is lost when you next upgrade kde, as the admin's installation probably doesn't work anymore. You'll be better off in the long run figuring out a way for kde3 to live under /usr. I think it's pretty clear what the consensus on using /opt in Debian is -- if you go ahead with this idea, you can probably start considering yourself a third party vendor. -- [EMAIL PROTECTED] http://spacepants.org/jaq.gpg I wore my extra loose pants for nothing. Nothing! -- Homer Simpson, New Kid on the Block
Re: [kde] setting an /opt precedent
Junichi Uekawa wrote:
> Current practice is to use /opt for external projects, and it is impossible
> to detect conflicts between Debian packages and external prrojects.
I certainly agree with this. An example might be the default installation of
oracle or another third party vendor. Personally, I consider /opt the dumping
grounds of software vendors that do not allow me, the sysadmin/user, access to
the files through anything but their fancy installation scripts. Many of these
scripts are difficult to customize. It's far easier to just dump the software
in /opt and sort it out later with symlinks to /opt/{bin,man,doc}.
I really don't consider the above situation appropriate for /usr/local, though
it could just as easily be used for that. I use /usr/local for those software
packages that I have access to the source code and may need to compile.
Another thing to consider. By default, there are few people who reserve space
for /opt either in / or as a separate partition. It's not really a problem for
those who allocate a huge root partition and nothing else, but if we go by
precident, I think there'd be a large number of people very surprised to find
their / partitions (mine is about 100MB) filled up.
So, I definitely agree with Junichi's statement.
--
Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie
http://www.wookimus.net/| s.k.a. gunnarr
Get my public key, ICQ#, etc. Send email w/the Subject: "get help"
Re: KMail and GPG
On Thu, Jan 17, 2002 at 06:00:24PM +0100, Laurent Rathle wrote: > I've generated a key with 3 different UID with GPG. I affected each one to an > identity in KMail. When I sign my message, KMail always use the same identity > for the three. Is it possible to have a key with three UID with KMail ? A signature is done with a key, not a UID. KMail is simply using some identifying information from the key when prompting you. If you wish to have recipients be able to distinguish between UIDs in the signature of the message then you need to generate a different key for each UID. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." pgpNRjfFMqMMV.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 15:21, Daniel Stone wrote:
> You might note the discussion on debian-kde of late, where Eray is
> attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> first disclose my viewpoint: I think this idea sucks, as you can clearly
> see from my postings.
>
> My main concern is that we'll set a precedent here in Debian for this
> sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> fact I'm pretty sure it doesn't even exist on a default install.
>
> So, please read the thread and state your opinions. I know it's a KDE
> issue, but I feel it affects Debian as a whole, since putting something
> in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> major precedent for Debian.
There was much argueing with Debian policy and FHS to decide what is
allowed and not. Fortunately there is no need to use them at all to
decide what's good and what's bad or right and wrong.
Just look at the organizaton of the tree used Kby DE, Gnome, X11,
apache or any other of the big software projects. All those projects
do what Debian tries to do with all of them together in a subtree
starting at '/'.
The common view, all apps use, users and admins see,
is the filesystem. That's why the 'subtree' approach sucks.
Everyone sees this loosely coupled stuff lying around
but what he/she really wants is a tidy and well organized
subtree '/'.
Sometimes projects talk to each other, like the window
manager developers and now it's possible to exchange them.
Nothing to do for Debian. Good for Debian and it's users.
Sometimes projects start a discussion, like KDE and Gnome
with the .desktop files. If this ever find an solution,
and other tools support it (also the tools that don't use X11)
Debian can through away it's menu system. Good, less work
for Debian developers. Good for the user.
But in most of the problematic fields of interoperation
projects have not started to find a common solution and
there Debian tries with it's policy and the FHS to do
what the projects don't do. Hard job for Debian
developers. Good for the Debian users.
We know from software that decoupled system are easier to
handle. That's why most distros choose the /opt/
approach. But the Admins and User sooner or later see
the big picture: it's just set of decoupled systems that
play more or less (if at all) well together.
IMO what's needed are better ways to replace/test/rollback
large collections of packages. Then no one will need or
miss the /opt/ approach.
Unfortunately I have no solutions for this problem, but I'm
very thankful that so many Debian developers work so hard in
their free time to make the subtree '/' a better place.
Achim
--
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: Summary of KDE filesystem discussion
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > The trend is to hide the differences between storage devices, not to > make it visible to the user. This is true, but I'd say it differently. More than saying "trend", I think better to just say "it's right".
Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 16:26, Eray Ozkural (exa) wrote: > No, I would lean to interpreting package installation as explicit assent to > overwrite files contained in the package, and removal to remove files. That's not good enough, because you often don't know what files a package contains when you "apt-get install" it. Suppose, for example, that I added /var/spool/mail/exa to, oh, cupsys. Do I automatically gain your permission to overwrite your mail spool, just because you use cupsys and typed "apt-get upgrade"? One can only assume that packages have permission from the sysadmin to overwrite or remove files in a manner consistent with Debian policy (which includes the FHS). Any more lax assumption about the sysadmin's intent inevitably leads to an eradication of all policy if applied consistently. (This applies only to official Debian packages. As has been pointed out, you're certainly free to do your own packages and put things wherever you want.) > I see. However, it is not very clear whether that phrase has any meaning. If > it's going to be practically impossible for distributions to install files in > /opt, why is it allowed in the first place? If it's going to be possible for > a local system administrator to form his own packages under various > /opt/ then why isn't a location in /usr/local adapted for this > purpose? Who is going to maintain the packages under an /opt/? > System software or the local administrator? That paragraph doesn't seem to be > consistent at all, and it isn't a good division of responsibility. Generally, I interpret the FHS this way: /usr -> package management system /usr/local -> source tarball installs /opt -> Windows-style binary installs w/ a foreign installer. Thus, /opt isn't a distro issue at all; it's there to accomodate people like Loki. Of course, that's just my interpretation, and my preference in setting up my own systems. One possible scenario where a Debian package may install into /opt would be a hypothetical "opt-manager". This package could iterate through /opt/* and create symlinks from /opt/*/bin into /opt/bin, possibly with some GUI that allowed the admin to turn packages in /opt on and off, install new packages into /opt, whatever. Since all of this would be done via interaction with the sysadmin, it's all allowed under the FHS. It could even be done automatically, as long as the package included debconfage to alert the sysadmin to the fact and offer to disable the automatic stuff.
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 18 January 2002 00:06, Yven Johannes Leist wrote: > > nice ice to hear :-) > > BTW this is sort of offtopic now, but what is the current state of the > objprelink kde and qt optimizations? > After Ivan decided not to do this any longer, I tried to do it myself, but > just ended with a completely broken libqt and kde packages :-) > Any ideas how to do this properly, or when this much needed optimization > will be in the official kde packets again (either via objprelink or of > course even better through new binutils) ? I will try to do it in my own build environment, and if I have any success I will tell Chris who maintains KDE3 packages. You are correct, any optimization is needed. If somebody paid me to develop for KDE, the optimizations for linking and XML UI would be my first priority. It takes like 5 seconds to start konqueror, it's insane. A desktop environment should be usable on a low-end system. 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 iD8DBQE8R0u8fAeuFodNU5wRAg22AJ9q8ZkBFutU7ld7BuGn6U+7xLgE0gCfbNxa y7VfMXTTJS7YOGdOIGOeOPc= =C8iJ -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 21:25, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 22:03, Yven Johannes Leist wrote: > > concerning a) I think the agreement (as I understood it) to move > > /usr/share/icons to/ usr/share/kde/icons is definitely a very good > > starting point to make people happier about the namespace pollution in > > /usr/share. concerning b): I definitely know that this is not exactly > > trivial and since I'm not doing anything to help, it's definitely just a > > wish and not to be considered as a criticism of the current situation in > > any form > > Well it's quite trivial, it's a matter of changing a few files. Not much > work. nice ice to hear :-) BTW this is sort of offtopic now, but what is the current state of the objprelink kde and qt optimizations? After Ivan decided not to do this any longer, I tried to do it myself, but just ended with a completely broken libqt and kde packages :-) Any ideas how to do this properly, or when this much needed optimization will be in the official kde packets again (either via objprelink or of course even better through new binutils) ? Regards, Yven -- Yven Leist - [EMAIL PROTECTED] http://www.leist.beldesign.de
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 23:42, Daniel Stone wrote: > > Have you even talked to Chris privately about this? I think on IRC today. 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 iD8DBQE8R0ZofAeuFodNU5wRArqGAKCIAJtRpkgwyyEYIAp77xDZtzeg7gCfZYMX 0RqxALFGapr2c31cvUpHpBc= =SrWT -END PGP SIGNATURE-
Re: KMail and GPG
On Thu, Jan 17, 2002 at 06:00:24PM +0100, Laurent Rathle wrote: > > Hello, > > I've generated a key with 3 different UID with GPG. I affected each one to an > identity in KMail. When I sign my message, KMail always use the same identity > for the three. Is it possible to have a key with three UID with KMail ? Do you mean 3 UIDs, or 3 email addresses? IIRC the two are quite distinct. If you mean email addresses, then you don't get to pick which one you sign with; it's just the last one added. -- Daniel Stone<[EMAIL PROTECTED]> vi is like wordstar with the endorphines rplaced with a lot of amphetamines cut with draino it's a rush pgpiw4ge6N74N.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 10:25:02PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 22:03, Yven Johannes Leist wrote: > > > > concerning a) I think the agreement (as I understood it) to move > > /usr/share/icons to/ usr/share/kde/icons is definitely a very good starting > > point to make people happier about the namespace pollution in /usr/share. > > concerning b): I definitely know that this is not exactly trivial and since > > I'm not doing anything to help, it's definitely just a wish and not to be > > considered as a criticism of the current situation in any form > > Well it's quite trivial, it's a matter of changing a few files. Not much work. > > I was asking people's opinions such as "I'm considering improving debian > packaging, these are some of the options, what do you want?". The discussion > somehow jumped to debian-devel, not by my wish and lasted for too long. Improving the packaging is an activity that needs to be undertaken with the actual maintainers, which you are not (Chris is the relevant maintainer here). If you read your beloved Policy carefully, you'll notice that you can't NMU (by the same token, neither can I); you need the full co-operation of maintainers to do anything. Have you even talked to Chris privately about this? -- Daniel Stone<[EMAIL PROTECTED]> but tell me...I have an app for tk ? where should i run it? CarpeDiem: in a contained environment. on a non-networked box. wouldn't want it to spread. pgpG7WW2odt7r.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 23:33, Daniel Stone wrote: > As I keep telling you, KDE developers are upstream. We're Debian. We > decide what goes where when you type "apt-get install kde". Without > condescention, they pump out a desktop environment, we package it. The > two generally don't overlap and shouldn't. Leave the distributing to the > distributors. > > The two arguments I've heard from you so far can be boiled down to: > * Solaris, SuSE, does it, so it must be > good! > * KDE hackers think it's k00l! ^^^ Your analysis is right. The latter was the basis of my argument. I give up on /opt, it's impossible to put files in /opt even if FHS allows it. I should also give up on /usr/lib/kde3 because nobody liked that idea; I've asked people on #kde and here on debian-kde now, it's enough. The /usr/share/kde change that calc said he's going to make should be enough. 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 iD8DBQE8R0PqfAeuFodNU5wRAoltAKCOG0rbdo5WCzMSY2SENn1YKRLxdQCgpg3U e+fDC8SLPqUgAXXkk7ruFvg= =mFEb -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 11:28:35PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 23:28, Daniel Stone wrote: > > [1]: Well, actually they're right, but I don't want to say that in > > public." > > Of course they are right to some extent, but I had to reserve it for a > footnote. Why, because you didn't want to say so in the body? -- Daniel Stone<[EMAIL PROTECTED]> * Overfiend sighs Netscape sucks. It is a house of cards resting on a bed of quicksand. during an earthquake in a tornado pgp2BqpFuwh7R.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 11:26:08PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 23:11, Jeff Licquia wrote: > > Somehow, I doubt that was the intended meaning of the FHS. > > I see. However, it is not very clear whether that phrase has any meaning. If > it's going to be practically impossible for distributions to install files in > /opt, why is it allowed in the first place? If it's going to be possible for > a local system administrator to form his own packages under various > /opt/ then why isn't a location in /usr/local adapted for this > purpose? Who is going to maintain the packages under an /opt/? > System software or the local administrator? That paragraph doesn't seem to be > consistent at all, and it isn't a good division of responsibility. We can't touch what an admin puts there without violating the FHS. I don't think that typing "apt-get install kde" is explicit assent, because we haven't asked the user a question like: "Hi, just calling to say that we're going to stomp all over your installation in /opt! Cool? (y/n)". It's even less cool because we do what no other Debian package has ever done - install to /opt. Remember that principle of least surprise I told you about a while ago? Don't mess with it. -- Daniel Stone<[EMAIL PROTECTED]> Wait, I have something for you all Romeo and Juliet in 1337! pgpPqCIBRhFeR.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 09:47:51PM +0200, Eray Ozkural (exa) wrote: > Aside from discussion of /opt policy in FHS: > Note that the mere suggestion of putting KDE files in /opt/kde3 was because > the above reason is not valid for KDE since it is quite different from the > majority of software packages which are smaller pieces of software designed > according to GNU Coding Standards. As a matter of fact, KDE also obeys GNU > Coding Standards to some extent but it is a very large system and therefore > many kde developers feel that it deserves its own directory; somewhat like > X11. That's all. As I keep telling you, KDE developers are upstream. We're Debian. We decide what goes where when you type "apt-get install kde". Without condescention, they pump out a desktop environment, we package it. The two generally don't overlap and shouldn't. Leave the distributing to the distributors. The two arguments I've heard from you so far can be boiled down to: * Solaris, SuSE, does it, so it must be good! * KDE hackers think it's k00l! -- Daniel Stone<[EMAIL PROTECTED]> (britney's subscribed to -devel-changes...) sick sick sick * asuffield observes that britney is a collossal hack Overfiend: you don't want to see how it handles the RC buglist, then ;) subscribes to debian-bugs-dist? :-P pgpQIKeCrJW83.pgp Description: PGP signature
Problem with Flash plugin in Konqueror
Hi Flash doesn't work in Konqueror on my Woody installation. Scenario: o I have the Flash plugin in ~/nsplugins o ~/nsplugins is the only directory for plugins in my Konqueror setup o Konqueror finds the plugin and lists it in the Plugins tab o When opening a page using Flash I get two Macromedia windows telling me to download Flash o I have installed the Blackdown JDK 1.3 and Java applets are working fine in Konqueror. Any help will be greatly appreciated -- mvh Jeppe _ ...film, bøger og musik: http://www.kultursnak.dk/
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 23:28, Daniel Stone wrote: > > [1]: Well, actually they're right, but I don't want to say that in > public." Of course they are right to some extent, but I had to reserve it for a footnote. Cheers, - -- 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 iD8DBQE8R0IDfAeuFodNU5wRAh+QAJ9vsDnKfdjn0Ht1awtR9DjijJn6mgCcDE2+ PDoPUOqcSLdsCgAxIanzTcw= =SiAw -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 23:11, Jeff Licquia wrote: > > When you run, say, "apt-get install kde", you are not given any hints at > that time about exactly what files will be removed, replaced, etc. > (except for the special case of conffiles). The only guide you have > there is the FHS and Debian policy; for example, you can assume with a > fair bit of confidence that installed-from-tarball KDE apps in /usr will > be overwritten, because that's where the FHS says that a vendor can muck > about at will. Similarly, you can assume with confidence that KDE apps > in /usr/local will not be so overwritten. > > Users read in the FHS a reassurance that a vendor cannot overwrite > anything the admin sticks in /opt without asking permission. Therefore, > any package that installs files in /opt needs to check that those files > don't exist already and prompt the admin if they do. > Yes, sort of like what kernel packages do. It would be very annoying if KDE packages did that for instance. Certainly not acceptable. > In short (as someone else has already joked), all files packages install > to /opt need to be treated as conffiles per the FHS. This would > definitely be an abuse of the conffile system. > :) That would be a far-fetched abuse. > > It would seem to imply for instance if I have installed a package foo in > > /opt/foo, the system must not overwrite files in /opt/foo without my > > knowledge. However, this paragraph doesn't seem to be very consistent to > > me since distributions can be said to provide the "assent of local system > > administrator" in any case... It's a matter of interpretation. > > If you interpret package installation as explicit assent from the > sysadmin to violate policy, then you have just nullified policy in its > entirety. Without a policy, we can do anything we want, including > install KDE to /opt. :-) > No, I would lean to interpreting package installation as explicit assent to overwrite files contained in the package, and removal to remove files. > Somehow, I doubt that was the intended meaning of the FHS. > I see. However, it is not very clear whether that phrase has any meaning. If it's going to be practically impossible for distributions to install files in /opt, why is it allowed in the first place? If it's going to be possible for a local system administrator to form his own packages under various /opt/ then why isn't a location in /usr/local adapted for this purpose? Who is going to maintain the packages under an /opt/? System software or the local administrator? That paragraph doesn't seem to be consistent at all, and it isn't a good division of responsibility. > > Policy is frozen, as it should be. Take the issue back up after woody > releases. Ah, sure. It's frozen already. I must append another line to the never finishing TODO list. :) 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 iD8DBQE8R0FxfAeuFodNU5wRAqr0AJ9fDzwxzO6vyLIjSG+RLguTK8VuAQCfdfn5 0MmHMT0WBhfvQtB6izKx4vQ= =ypB0 -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 07:21:59PM +0200, Eray Ozkural (exa) wrote: > [+] The other typical response that "Well it may not violate the policy, but > it does not seem to be consistent with other packages." is a much more valid > one. I can't beleve you relegated this to a footnote. That's like saying: "But everyone's, of course, wrong, and I'm right.[1] blah blah blah blah blah blah Cheers, Eray [1]: Well, actually they're right, but I don't want to say that in public." -- Daniel Stone<[EMAIL PROTECTED]> * Overfiend_ can't recall reading about Francois MITTERAND or Georges CLEMENCEAU, let alone Napoleon BONAPARTE. Or Louis THE FOURTEENTH Overfiend_: None of them were Japanese. pgpbucjGPKssI.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 02:37 pm, Eray Ozkural (exa) wrote: > For the record, I'm *not* saying that KDE should be installed in /opt. This > is another matter, I'm saying that the reason for not installing into /opt > cannot be "/opt violates FHS" since /opt is part of FHS, and its use is > very clearly conveyed in the standard. I'd like to think that a native > English speaker would not have so much difficulty in understanding two > pages of text. Then perhaps this discussion should continue on a policy list or in private, since it's pretty off-topic for this list, by your own admission. > For people who are more seriously interested in the interpetation of FHS, I > invite you to thoroughly read the standard and state your opinions. > > 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 > > iD8DBQE8RygCfAeuFodNU5wRApgZAJ9JHFAFLC0z/DgTzn53ODqsIF4qUwCghqyy > hfFVKamR+48M5hirLe29094= > =83Uo > -END PGP SIGNATURE-
Desktop redraws
Hi, i`m using woody and kde 2.2.x. When i activate an icon on the desktop the desktop redaws himself, but the programm doesn`t start. The same problem is, when i dragging an icon out of the menue on the desktop and click on the icon. Is this a known problem? Greets, Christian -- # 249406
Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 15:00, Eray Ozkural (exa) wrote: > > On Thursday 17 January 2002 21:44, Jeff Licquia wrote: > > > > We cannot currently ensure that a package installing to /opt cannot > > overwrite admin-installed software there. > > > > Thanks for the explanation. That's a quite vague statement. How does one > modify or delete software ... without the assent of the local system > administrator? After all, it is the local system administrator who runs the > packaging commands. Theoretically, there isn't much difference between > running dpkg or rm. When you run, say, "apt-get install kde", you are not given any hints at that time about exactly what files will be removed, replaced, etc. (except for the special case of conffiles). The only guide you have there is the FHS and Debian policy; for example, you can assume with a fair bit of confidence that installed-from-tarball KDE apps in /usr will be overwritten, because that's where the FHS says that a vendor can muck about at will. Similarly, you can assume with confidence that KDE apps in /usr/local will not be so overwritten. Users read in the FHS a reassurance that a vendor cannot overwrite anything the admin sticks in /opt without asking permission. Therefore, any package that installs files in /opt needs to check that those files don't exist already and prompt the admin if they do. In short (as someone else has already joked), all files packages install to /opt need to be treated as conffiles per the FHS. This would definitely be an abuse of the conffile system. > Moreover, if you consider the context of the above quote: >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. > > It would seem to imply for instance if I have installed a package foo in > /opt/foo, the system must not overwrite files in /opt/foo without my > knowledge. However, this paragraph doesn't seem to be very consistent to me > since distributions can be said to provide the "assent of local system > administrator" in any case... It's a matter of interpretation. If you interpret package installation as explicit assent from the sysadmin to violate policy, then you have just nullified policy in its entirety. Without a policy, we can do anything we want, including install KDE to /opt. :-) Somehow, I doubt that was the intended meaning of the FHS. > > As you yourself have mentioned, if you don't like the plain text of the > > FHS as presented, take it up with them. > > No, I don't like it. > > However, I am not very good at writing concise statements fitting for FHS, > and I am not yet a developer either. Could you please take up this small task > and add an interpretation of the above statement to the Debian Policy? I > think it should be in the form of "We cannot install any files in /opt, since > Debian has no way of tracking what local software system administrator may > have installed." I think such a clarification is needed since there is a > dangling ambiguity. Policy is frozen, as it should be. Take the issue back up after woody releases.
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 January 2002 02:24 pm, Eray Ozkural (exa) wrote: > The reason is that Ivan's yet untested approach will not work well > when users want to install KDE2 and KDE3 at the same time. > > In my approach, you can choose among KDE2 or KDE3 to your heart's > content. Note that the only file conflicts will *not* happen among > libraries, which is why you should install in a KDE prefix other than > /usr. There are many files that conflict, from the ground up. And > there is no easy solution except implementing my proposed approach. While this packaging/FHS KDE stuff is over my head, as a user and since it is being heavily air on the kde -user list I have a user comment. It seems to me that there would be only one version of KDE in Debian stable. How Debian gets to one version in stable is another matter. - -- Greg Madden -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxHO/QACgkQaefA3q8KcpD6xgCfdO171l4+ZqQhY/72JgB6wE+f lWMAmweuFicejMFd9Nncc9Sosuqqq5Gv =LS8K -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 08:47 pm, you wrote: > > So, what are the "reasons behind Debian not mucking about with > /opt" except the preconceptions of some developers? I think you > would have to say something like: > > * It is not very consistent with the directory layout many packages > adapt > > Is there any other reason? I assume none, since front end files can > be placed by the distribution in usual locations by symlinking or > by wrapper scripts. The reasons are not "preconceptions," but opinions based on experience with older UN*X systems that had such a layout. My personal reason is the PATH variable. When I was a sys admin at university, we had to maintain the default PATH for all users in a lab. Doing this for all the different packages that went into /usr/local/foo/bin, /opt/bar/bin, and /usr/pkg/baz/bin was a pain in the butt. I also think that your proposed solution of using symlinks and wrapper scripts are inelegant hacks. > Actually the FHS permits use of /opt by distributions you mean. > Please add it to the policy if you have a logical rationale but > then we will have to drop "FHS compliance" from the list of > Debian's features. ;) Just because Debian chooses to disallow something that is permitted (but not required) by the FHS does not make Debian uncompliant with the FHS. > Aside from discussion of /opt policy in FHS: > Note that the mere suggestion of putting KDE files in /opt/kde3 was > because the above reason is not valid for KDE since it is quite > different from the majority of software packages which are smaller > pieces of software designed according to GNU Coding Standards. As a > matter of fact, KDE also obeys GNU Coding Standards to some extent > but it is a very large system and therefore many kde developers > feel that it deserves its own directory; somewhat like X11. That's > all. Your statement is that KDE is different from other software because of its size, and it should be treated differently because of that. I don't think that matters. X11 is a special case because it's been there so long. The FHS is explicit about that: "No large software packages should use a direct subdirectory under the /usr hierarchy. An exception is made for the X Window System because of considerable precedent and widely-accepted practice." Unfortunately, the FHS doesn't explain it's reasons for this prohibition, but I agree with it, so I don't need convincing. That's all, Frank
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 22:03, Yven Johannes Leist wrote: > > concerning a) I think the agreement (as I understood it) to move > /usr/share/icons to/ usr/share/kde/icons is definitely a very good starting > point to make people happier about the namespace pollution in /usr/share. > concerning b): I definitely know that this is not exactly trivial and since > I'm not doing anything to help, it's definitely just a wish and not to be > considered as a criticism of the current situation in any form Well it's quite trivial, it's a matter of changing a few files. Not much work. I was asking people's opinions such as "I'm considering improving debian packaging, these are some of the options, what do you want?". The discussion somehow jumped to debian-devel, not by my wish and lasted for too long. I wish I had some time to do the /usr/share/kde3 change right now, but I don't have the time for the huge build and test process; I have an important deadline approaching... :/ I will try to do the necessary changes (if Chris hasn't done them yet) when I become available. Regards, - -- 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 iD8DBQE8RzMefAeuFodNU5wRAgGTAJ41wg5Z+zeh76yCHR3Fi6hiX3BMRwCgnnQL uOtLmQqsLYc+OFGDKEOuo1s= =JyCL -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Junichi, On Thursday 17 January 2002 20:04, Junichi Uekawa wrote: > > Current practice is to use /opt for external projects, > and it is impossible to detect conflicts between Debian packages and > external prrojects. > > It might be nice to add this bit of policy to Debian Policy > so that people do not start mucking around with /opt. > I think that's a good idea, since an interpretation of the statement in question is required. I agree with Jeff and you on this matter. Perhaps you or him, as debian developers, could write a one sentence addition to FHS that clarifies the situation for once and all? Regards, - -- 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 iD8DBQE8RzWZfAeuFodNU5wRAgrUAKCYqEIrDm5t82+k2dYG8XgNEpAnwgCgk/s0 IZdh38vcENPam8sVhX8Jxvs= =N0Sp -END PGP SIGNATURE-
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
On Thursday 17 January 2002 16:10, Daniel Stone wrote: > On Thu, Jan 17, 2002 at 04:57:33PM +0200, Eray Ozkural (exa) wrote: [...] > > I suggest you to at least implement: "/usr/share/kde3" under which all KDE3 > > ro arch indep data should go in such as "/usr/share/kde/icons". Icons are excatly the example that shows that /usr/share/kde* is the wrong thing... > I have no beef with this. This is the sort of sane suggestion I wish > you'd come up with more frequently. I've always thought this should be > done, as /usr/share is just too cluttered. ... Please don't do this. Please keep same logical things, like icons, together. Otherwise searching for icons is a night mare. I've dirs get too crowed use subdir like /usr/share/icons/kdeX /usr/lib/kdeX That's okay but not optimal (IMO). KDE did the right thing (tm). Below icons is hi/locolor, then size subdirs. Because KDE does not care what kde package an icons comes from. In an ideal Debian system it would be the same, KDE, Gnome, fvwm ... put all their stuff together, because Debian does not care which packages includes the icons. At least that is my dream everytime the icons dialog pops up, and KDE has not the right one. If one want a view on files by package nothing can do better than the package tools. We don't need the filesystem for it. If one wants a bigger groups add eg. tags to packages so one can do apt-get update --tag kde -t unstable upgrade dpkg --tag kde -l Joe user looks for docs, icons, sounds ... Keep it together and Joe user is happy. Add good package tools and admin is happy. If both are happy you are on a Debian system ;) At least up to now. I hope it will not change. Achim [...] -- 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] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 21:47, Eray Ozkural (exa) wrote: > Actually the FHS permits use of /opt by distributions you mean. Please add > it to the policy if you have a logical rationale but then we will have to > drop "FHS compliance" from the list of Debian's features. ;) If we write it in the form of "interpretation of a paragraph in FHS", then Debian will have remained FHS compliant. 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 iD8DBQE8Ry3rfAeuFodNU5wRAjJRAJ44wioli1KJMnZb/Ip4O6X4hAYc7QCeJwPl kjaFumgFu+lOJQgNoZXNrbA= =iJHO -END PGP SIGNATURE-
Re: filesystem discussion (my 2 cents)
Le Jeudi 17 Janvier 2002 11:38, Maximilian Reiss a écrit : > Ok, > > having both (kde2 and kde3) in debian the both time might not be the best > idea. > Disadvantages: > - quite some trouble regarding where the files should go .-) > - would waste lots of diskspace on the mirrors. > > - Is it really needed? KDE3 supplies improved version of all kde core > apps, and is normally stable on release date. > > So heres my suggestion: > KDE3 is kept out of debian as long as it is really released. (KDE3 release, > probably a little bit later to catch some hot cvs upstream fixes .-) ). > The KDE3 moves into debian, and replaces KDE2, at least all the apps, that > are allready ported to KDE3. > For the other apps the kde2 kdelibs and kdebase-libs (probably some more) > will stay in debian, als long as there are KDE2 apps not ported to KDE3. > Same for the -dev packages, since it should still be possible to compile a > KDE2 app and run it. > > This would cut the discussion above and would prevent a lot of trouble. > Also we would get a hug from the mirror maintainers. > > Until the release of KDE calc could supply beta (KDE3 RC1) debs from an > external apt source. (p.d.o). > Here it could be considerable to use the --prefix=/opt/kde3 (optional > package) as long as it stays external and then change the prefix to /usr if > it gets close to release time, or from an apt source as replacement > allready for the installed kde2, conflicting. > I totally agree with you. Unofficial/unstable versions of KDE can be imho considered to be add-ons, and should go into /opt
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jeff, On Thursday 17 January 2002 21:44, Jeff Licquia wrote: > > That is not what the text of the FHS says. There is no limitation > mentioned that states that the admin cannot install software outside of > /opt/bin, etc. And, wherever in /opt the admin decides to install > software, packages "should not modify or delete software installed by > the local system administrator without the assent of the local system > administrator." Period. > > We cannot currently ensure that a package installing to /opt cannot > overwrite admin-installed software there. > Thanks for the explanation. That's a quite vague statement. How does one modify or delete software ... without the assent of the local system administrator? After all, it is the local system administrator who runs the packaging commands. Theoretically, there isn't much difference between running dpkg or rm. Moreover, if you consider the context of the above quote: 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. It would seem to imply for instance if I have installed a package foo in /opt/foo, the system must not overwrite files in /opt/foo without my knowledge. However, this paragraph doesn't seem to be very consistent to me since distributions can be said to provide the "assent of local system administrator" in any case... It's a matter of interpretation. > As you yourself have mentioned, if you don't like the plain text of the > FHS as presented, take it up with them. No, I don't like it. However, I am not very good at writing concise statements fitting for FHS, and I am not yet a developer either. Could you please take up this small task and add an interpretation of the above statement to the Debian Policy? I think it should be in the form of "We cannot install any files in /opt, since Debian has no way of tracking what local software system administrator may have installed." I think such a clarification is needed since there is a dangling ambiguity. I think your message wraps up the discussion. Thanks again. Regards, - -- 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 iD8DBQE8Ry14fAeuFodNU5wRAqaGAJ0R9btpbJ0d27umK2xoBtp9hwgNAgCfYcSw 9bMbvSCZlccJ7KifnmL9MLQ= =c79u -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 15:21, Daniel Stone wrote:
> You might note the discussion on debian-kde of late, where Eray is
> attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> first disclose my viewpoint: I think this idea sucks, as you can clearly
> see from my postings.
>
> My main concern is that we'll set a precedent here in Debian for this
> sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> fact I'm pretty sure it doesn't even exist on a default install.
>
> So, please read the thread and state your opinions. I know it's a KDE
> issue, but I feel it affects Debian as a whole, since putting something
> in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> major precedent for Debian.
>
I think it's important to see that there are lots of people (including me),
who are definitely against putting packages in /opt (which would be really
stupid in my opinion, even if the FHS allows it), but whose problem is more
that
a) the current layout really clutters especially /usr/share just a bit too
much, and
b) it would be really nice to be able to install kde2 and kde3 separately,
since, at least in my experience, getting kde3 from cvs is really so much
more time consuming and error-prone that separate kde3 packages would
definitely help a lot of people in trying and testing kde3.
concerning a) I think the agreement (as I understood it) to move
/usr/share/icons to/ usr/share/kde/icons is definitely a very good starting
point to make people happier about the namespace pollution in /usr/share.
concerning b): I definitely know that this is not exactly trivial and since
I'm not doing anything to help, it's definitely just a wish and not to be
considered as a criticism of the current situation in any form
Regards,
Yven
--
Yven Leist - [EMAIL PROTECTED]
http://www.leist.beldesign.de
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 11:37 am, Eray Ozkural (exa) wrote: > > It should - but as of my current base-files, it does not. /opt should be > > created as the FHS calls for it to be for third party software. KDE is > > not third party software in Debian. > > So it seems you were the smart person who thought "add-on" in FHS > necessarily meant "third party" although there is not the slightest > implication of such a thing in FHS itself. > You make an interesting point - the FHS very clearly states: "Distributions may install software in /opt..." It also calls the restrictions placed on distributions using /opt "minor." I suppose the closest thing Debian has to add-on software would be packages with priority optional or extra. I agree that installing KDE into /opt sucks, and (technical implementation problems aside) while it does not violate the FHS, it violates my sense of aesthetics.
Re: [kde] setting an /opt precedent
"Eray Ozkural (exa)" <[EMAIL PROTECTED]> cum veritate scripsit: > There is an _invalid_ reason which I had to iterate over and over again: > * /opt is reserved for system administrator's use. > NO! Certain subdirectories of /opt are reserved for local system admin. The > rest of /opt can be used by the distribution, as explained in FHS with a > language that a high school student can easily understand. Please back your argument with a quote I fail to find it. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: kde not starting as normal user
Hello folks, i found this while debugging my kde-problem DCOPServer up and running. >> running as realtime process now (priority 50) cp: Zugriff auf »/root/Desktop/Mülleimer//.directory«: Keine Berechtigung QWidget::setMinimumSize: The smallest allowed size is (0,0) QWidget::setMinimumSize: The smallest allowed size is (0,0) But i was not able to find the reason for this.. Bis dann & Gruß Marc
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings Frank, On Thursday 17 January 2002 21:32, Frank Murphy wrote: > On Thursday 17 January 2002 07:04 pm, Junichi Uekawa wrote: > > It might be nice to add this bit of policy to Debian Policy > > so that people do not start mucking around with /opt. > > This is a good idea. I understand and whole-heartedly agree with the > reasons behind Debian not mucking about with /opt, but looking at the > quoted parts of the FHS, it isn't clear that distributions may not > install packages into /opt. Adding it to Policy would clarify that. > So, what are the "reasons behind Debian not mucking about with /opt" except the preconceptions of some developers? I think you would have to say something like: * It is not very consistent with the directory layout many packages adapt Is there any other reason? I assume none, since front end files can be placed by the distribution in usual locations by symlinking or by wrapper scripts. There is an _invalid_ reason which I had to iterate over and over again: * /opt is reserved for system administrator's use. NO! Certain subdirectories of /opt are reserved for local system admin. The rest of /opt can be used by the distribution, as explained in FHS with a language that a high school student can easily understand. Actually the FHS permits use of /opt by distributions you mean. Please add it to the policy if you have a logical rationale but then we will have to drop "FHS compliance" from the list of Debian's features. ;) Aside from discussion of /opt policy in FHS: Note that the mere suggestion of putting KDE files in /opt/kde3 was because the above reason is not valid for KDE since it is quite different from the majority of software packages which are smaller pieces of software designed according to GNU Coding Standards. As a matter of fact, KDE also obeys GNU Coding Standards to some extent but it is a very large system and therefore many kde developers feel that it deserves its own directory; somewhat like X11. That's all. Regards, - -- 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 iD8DBQE8RypnfAeuFodNU5wRAmTsAKCLD2+abQdhjmIAs7aWbtuY5WU2CwCeN86q DqfakVW1jsmex4rj8Cp/NoQ= =+asl -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 14:26, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 20:04, Junichi Uekawa wrote: > >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. > > > > Tell me how you achieve the above, with Debian packages touching > > /opt/kde > > > > As explained in section 3.8, it is obvious. Local system administrator, as I > have written, manages the contents of the following directories. > /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man > > A distribution therefore cannot touch the content of these subdirs, however > it can install software in a package directory > /opt/ > under which the files pertaining to are maintained. FHS explicity > allows this. That is not what the text of the FHS says. There is no limitation mentioned that states that the admin cannot install software outside of /opt/bin, etc. And, wherever in /opt the admin decides to install software, packages "should not modify or delete software installed by the local system administrator without the assent of the local system administrator." Period. We cannot currently ensure that a package installing to /opt cannot overwrite admin-installed software there. As you yourself have mentioned, if you don't like the plain text of the FHS as presented, take it up with them.
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 21:20, Joseph Carter wrote: > On Fri, Jan 18, 2002 at 01:21:07AM +1100, Daniel Stone wrote: > > You might note the discussion on debian-kde of late, where Eray is > > attempting to set a precedent by installing KDE3 into /opt/kde3. Let me > > first disclose my viewpoint: I think this idea sucks, as you can clearly > > see from my postings. > > Eray is being an idiot. > > /opt is user's territory, not ours. KDE is correct to default to using This is definitely not the case according to FHS. If you believe that /opt should be user's territory, please go and submit a patch to FHS maintainers and we will see who is the real idiot. > /opt according to the FHS for a default installation. But it is not > correct for Debian to put it there. > And the reason being "/opt is user's territory, not ours although doing so does not violate FHS". I'm hoping you don't seriously back this explanation of yours. You are failing to give any objective reasons. The only reason you have given is your own belief, which does not correspond to facts. For the record, I'm *not* saying that KDE should be installed in /opt. This is another matter, I'm saying that the reason for not installing into /opt cannot be "/opt violates FHS" since /opt is part of FHS, and its use is very clearly conveyed in the standard. I'd like to think that a native English speaker would not have so much difficulty in understanding two pages of text. > > It should - but as of my current base-files, it does not. /opt should be > created as the FHS calls for it to be for third party software. KDE is > not third party software in Debian. > So it seems you were the smart person who thought "add-on" in FHS necessarily meant "third party" although there is not the slightest implication of such a thing in FHS itself. For people who are more seriously interested in the interpetation of FHS, I invite you to thoroughly read the standard and state your opinions. 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 iD8DBQE8RygCfAeuFodNU5wRApgZAJ9JHFAFLC0z/DgTzn53ODqsIF4qUwCghqyy hfFVKamR+48M5hirLe29094= =83Uo -END PGP SIGNATURE-
Re: filesystem discussion (my 2 cents)
On Thursday 17 January 2002 11:38 am, Maximilian Reiss wrote: > Ok, > > having both (kde2 and kde3) in debian the both time might not be > the best idea.
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 20:04, Junichi Uekawa wrote: > "Eray Ozkural (exa)" <[EMAIL PROTECTED]> cum veritate scripsit: > > Prior to saying that, you should have read the relevant section in > > policy, seeing that it simply delegates all responsibility to FHS, read > > the relevant section 3.8 in FHS and conceived why I said debian packages > > may install files in /opt/. I also refer you to the thread > > titled "KDE Filesystem Structure", and messages in debian-kde explaining > > the situation: > > http://lists.debian.org/debian-kde/2002/debian-kde-200201/msg00317.html > >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. > > Tell me how you achieve the above, with Debian packages touching > /opt/kde > As explained in section 3.8, it is obvious. Local system administrator, as I have written, manages the contents of the following directories. /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man A distribution therefore cannot touch the content of these subdirs, however it can install software in a package directory /opt/ under which the files pertaining to are maintained. FHS explicity allows this. In any case, since distribution cannot install anything in the above mentioned subdirs, the front end files are to be placed in those directories controlled by the distribution such as /usr/bin. Regards, - -- 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 iD8DBQE8RyV7fAeuFodNU5wRArh8AJwJfFHKt2glUWap7p3O3mEV/x78hwCfYcB9 ySZbKn4k+7JVcXI+qLa6/aM= =JRD9 -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thursday 17 January 2002 07:04 pm, Junichi Uekawa wrote: > > It might be nice to add this bit of policy to Debian Policy > so that people do not start mucking around with /opt. This is a good idea. I understand and whole-heartedly agree with the reasons behind Debian not mucking about with /opt, but looking at the quoted parts of the FHS, it isn't clear that distributions may not install packages into /opt. Adding it to Policy would clarify that. Frank
Re: [kde] setting an /opt precedent
> "JC" == Joseph Carter <[EMAIL PROTECTED]> writes: JC> /opt is user's territory, not ours. KDE is correct to default JC> to using /opt according to the FHS for a default installation. JC> But it is not correct for Debian to put it there. Exactly. If I want to have 2+ versions of KDE, I'd like a structure to put it in, and /opt seems more appropriate than /usr/local. -- A.J. RossiniRsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics [EMAIL PROTECTED] FHCRC/SCHARP/HIV Vaccine Trials Net [EMAIL PROTECTED] -- http://software.biostat.washington.edu/ FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX --- I'm 40% time until March 1st. Try email the other 3 days -
Re: [kde] setting an /opt precedent
On Fri, Jan 18, 2002 at 01:21:07AM +1100, Daniel Stone wrote:
> You might note the discussion on debian-kde of late, where Eray is
> attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> first disclose my viewpoint: I think this idea sucks, as you can clearly
> see from my postings.
Eray is being an idiot.
/opt is user's territory, not ours. KDE is correct to default to using
/opt according to the FHS for a default installation. But it is not
correct for Debian to put it there.
> My main concern is that we'll set a precedent here in Debian for this
> sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> fact I'm pretty sure it doesn't even exist on a default install.
It should - but as of my current base-files, it does not. /opt should be
created as the FHS calls for it to be for third party software. KDE is
not third party software in Debian.
> So, please read the thread and state your opinions. I know it's a KDE
> issue, but I feel it affects Debian as a whole, since putting something
> in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> major precedent for Debian.
SuSE and Red Hat do not follow the FHS when they do so. We do follow it,
therefore we stay out of /opt.
--
Joseph Carter <[EMAIL PROTECTED]> glDisable (DX8_CRAP);
A subversive is anyone who can out-argue their government.
pgp6rBMRIwSkm.pgp
Description: PGP signature
Re: Fix for KDE source distributions
On Thursday 17 January 2002 16:03, James Thorniley wrote:
> Hi,
>
> I've done a patch for the acinclude.m4.in file which defines how source
> distributions find the KDE install dirs that should make it work around the
> non standard layout in debian (see my earlier posts re: location of docs etc.
> someone has also mentioned the move of config files to /etc/kde2, which this
> should also work around).
Hi James,
great to see something get's done and beside all this flaming.
While the patch is a nice idea for one special case (complete private
build without a kde-config lying around before compilation) it will
give unexpected results in the other cases (I've only looked
at the diff so I may be wrong).
Unfortunately it does not a fix for Debian KDE:
o using kdeconfig from Debian gives you
/etc/kde2
/usr/bin
etc. But admins should install every non deb stuff
below /usr/local.
o problem with /etc/kde2 is not fixed. kde-config --install config
'always' returned /etc/kde2. Nevertheless it's not used during
run time (see below). Therefore for the config entry in /etc/kderc
is required and can not be used to define KDE stuff that's
installed below /usr/local/. :(
Here a demonstration of of the /etc/kde2 problem. I was too
stupid/sleepy to figure out what goes wrong in kdestdirs.* code :(
ds10(1) ~ > kde-config --install config
/etc/kde2
ds10(0) ~ > su - -c "mv /etc/kderc{,.save}"
Password:
ds10(0) ~ > kde-config --install config
/etc/kde2
ds10(0) ~ > kde-config --path config
/home/ach/.kde2/share/config/:/usr/share/config/
ds10(0) ~ > su - -c "mv /etc/kderc{.save,}"
Password:
ds10(0) ~ > kde-config --path config
/home/ach/.kde2/share/config/:/usr/share/config/:/etc/kde2/
ds10(0) ~ >
You see /usr/share/config is compiled into (kdestddir*)
not /etc/kde2. And this is the reason why /etc/kderc
is there at all.
I could not convience Ivan to use the less intrusive link
from /usr/share/config/ instead of /etc/. Both do the same thing:
ds10[0] ~ # dpkg-divert --local --rename --add /etc/kderc
Adding `local diversion of /etc/kderc to /etc/kderc.distrib'
ds10[0] ~ # ln -s /etc/kde2/system.kdeglobals
/usr/share/config/system.kdeglobals
ds10[0] ~ # kde-config --path config
/root/.kde/share/config/:/usr/share/config/:/etc/kde2/
So everything works as before but my KDE cvs build is not
f*** from time to time because it also uses /etc/kderc if
available. /etc/kderc can be really dangerous :(
Achim
> I haven't attached the patch because I'm not sure how much interest there
> would be on this list. If you would like a copy either email me or get it
> from my project on sourceforge
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kcast/kcast/admin/acinclude.m4.in
> It's only been hacked internally, so it should work as a drop in replacement
> for most KDE source distributions (might be worth a try if you cant get a
> distribution to install properly, anyway).
>
> Note this patch is a little dodgy since I'm not very experienced with
> automake, I'm going to write to the kdevelop mailing list and see if anyone
> is interested in taking a look to check I haven't actually screwed it in any
> obvious way ;) If it turns out ok I will submit it to Stephan Kulow who
> appears to be the current maintainer so it might get included somewhere
> upstream, but I suspect it will be undergoing modifications for KDE3 so I
> don't know how it would fit in.
>
> Thanks
> James
--
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] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 18:21, Eray Ozkural (exa) wrote: > However, unfortunately, your above statement > assumes that policy prohibits use of /opt while it does not, that > is it does not explain at all how, why, or where it is prohibited. > It is the same answer saying that "/opt violates policy" I heard > from many. What you don't seem to understand, though, is that quite a lot of people, including Daniel Stone who is the current maintainer, actually don't care about whether it violates FHS|Policy or not. They say: Using /opt/kde sucks. Reasons: 1. Sets bad precedent, what if all Debian packages worked this way? 2. How do you get the binaries into the path given the fact that you're not allowed to touch /opt/bin. 3. How can you be sure you're not messing with third-party or local administrator set up packages? I agree: Using /opt/kde sucks. And although I share your opinion that the current solution is not optimal, I think /opt/kde would be way worse. - -- - -M - --- Magnus von Koeller <[EMAIL PROTECTED]> -- Georg-Westermann-Allee 76 / 38104 Braunschweig / Germany Phone: +49-531-2094886 Mobile: +49-179-4562940 lp1 on fire (One of the more obfuscated kernel messages) -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8RxzMUIvM6e6BgFARAkKEAKDlpy9UsoC8UPBEelL2jeAiiDUcUwCfTzmE tv2+dxZHhBYsnInS6aG9bh4= =090r -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, 2002-01-17 at 10:34, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 17:22, Daniel Stone wrote: > > /opt is for "add-on" software. kde is not an "add-on". we package it as > > part of the distribution, it's not added on. > > That is a wrong reading of standard text. > > /opt -- Add-on application software packages > > There is a difference between system and application software. C++ library is > system software, while a desktop environment like KDE is application > software. System can continue functioning in the absence of such application > software that is optional, hence the expression "Add-on". By your logic, the phrase "add-on" therefore is a no-op. Standards are generally written such that all words add meaning, and interpretations that strip meaning from words or phrases are generally considered to be wrong unless there is no consistent way of interpreting them otherwise. In other words, the standard grammatically uses "add-on" as a modifier to "application software packages". We must therefore assume that the word does, in fact, modify the phrase. Since your interpretation causes no modifications, other interpretations must be preferred. Stated yet another way: My system functions fine without vi. Should we move all the vi clones to /opt/vim, /opt/nvi, /opt/elvis, etc.? Do we then install a symlink via alternatives for the "preferred" vi to /opt/vi, with /opt/vi/bin/vi the path to the preferred vi? All of this would be perfectly fine according to your interpretation of the FHS, yet it would destroy the spirit and purpose of the FHS: to provide a standard way for the system to lay itself out so users and third-party developers know what to expect. The reason: no one seriously would call vi an "add-on", even if it is an application software package. So, there must be a distinction between "add-on application software packages" and "other application software packages" (a distinction you deny). The final question to ask, then, is only whether we consider KDE to be an "add-on". We don't; it's in main, which is the only test the project accepts for some software to be "part of Debian". (Put another way: if KDE is "just an add-on", then what was all the fuss about back before Qt went GPL?) Therefore, KDE does not belong in /opt. QED. > As stated in section 3.8, distributions can install software in /opt in > accordance with FHS. > > Moreover, this is an established practice as emphasized in FHS standard text. Deliberate blockages are placed in the way of the distribution vendor by the standard, however. The restrictions on /opt/bin and so on imply that a package installed in /opt must be manually enabled by the sysadmin before it can be used. Is this what we want to do to poor KDE? Think again about /opt/vi. Most users would expect "apt-get install vim && vi foo" to work. But we can't add vi to /opt/bin, and we can't change the PATH of the parent shell to include /opt/vi/bin. So you have to log out of the shell you're in before you can use vi, or type "/opt/vi/bin/vi foo"? What if you ran the aforementioned command in a single-user shell, and couldn't exit without causing the system to go multi-user? And all of this is supposed to be an improvement? The implication is that, although distros are allowed to install into /opt, it is discouraged; it should only be done if really necessary. I have heard lots of reasons why it might or might not be allowable to install KDE into /opt, but no reasons why it might be necessary.
Re: [kde] setting an /opt precedent
"Eray Ozkural (exa)" <[EMAIL PROTECTED]> cum veritate scripsit: > Prior to saying that, you should have read the relevant section in policy, > seeing that it simply delegates all responsibility to FHS, read the relevant > section 3.8 in FHS and conceived why I said debian packages may install files > in /opt/. I also refer you to the thread titled "KDE Filesystem > Structure", and messages in debian-kde explaining the situation: > http://lists.debian.org/debian-kde/2002/debian-kde-200201/msg00317.html 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. Tell me how you achieve the above, with Debian packages touching /opt/kde Current practice is to use /opt for external projects, and it is impossible to detect conflicts between Debian packages and external prrojects. It might be nice to add this bit of policy to Debian Policy so that people do not start mucking around with /opt. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Junichi, On Thursday 17 January 2002 18:49, Junichi Uekawa wrote: > > If you are talking about random add-on packages that > is distributed from kde.org or whatever else, > that would be fine, as long as it is independent from Debian. > > We, as Debian, do not use /opt. > > We reserve it for third party software. > Well. No. > There might be a third party software which may want to install in > /opt/kde > > We allow that to happen. > > > Please read and understand the policy, and why we have a good > reputation on not having touched /usr/local. /usr/local and /opt are quite distinct. I appreciate your good intention in presenting your point of view. However, unfortunately, your above statement assumes that policy prohibits use of /opt while it does not, that is it does not explain at all how, why, or where it is prohibited. It is the same answer saying that "/opt violates policy" I heard from many. [+] Prior to saying that, you should have read the relevant section in policy, seeing that it simply delegates all responsibility to FHS, read the relevant section 3.8 in FHS and conceived why I said debian packages may install files in /opt/. I also refer you to the thread titled "KDE Filesystem Structure", and messages in debian-kde explaining the situation: http://lists.debian.org/debian-kde/2002/debian-kde-200201/msg00317.html There is absolutely *no* mention of /opt being reserved for third party vendors [!]. The FHS standard is written in a very plain language, and it explicitly says what is allowed and what is not allowed for distributions. I'm having to restate myself; it shouldn't be this difficult to read a section of a standard. The catch is that /usr/local is for local system administrator's use. Debian cannot install any files there. /opt is different. Let me repeat it. /opt is not the same thing as /usr/local. I will also have to restate that "add-on does not mean third party" as the FHS itself clarifies such a misunderstanding by explicitly and without doubt saying that distributions *can* install files in /opt/, however there are certain justified restrictions on using /opt. A set of subdirs of /opt, not /opt itself for those who are too lazy to read the standard itself, namely "/opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use". All components of a software package, on the other hand, should be installed in /opt/ directory tree. [*] There are also other rules such as the configuration of a package maintained in /etc/opt/. I'm hoping I have made it clear this time. Judging from the responses, it was needed. Before saying anything else, I recommend those interested to *read* that section of FHS in complete, and all other relevant sections, and then state your opinions. I have merely presented the facts. Of course, if you think FHS is badly designed in this respect you should be offering an improvement to FHS which should be directed to the fhs mailing list. AFAICT, removing /opt from the standard would not be an acceptable patch, however you may have thought of an improvement over the existing scheme. Regards, [+] The other typical response that "Well it may not violate the policy, but it does not seem to be consistent with other packages." is a much more valid one. [!] It is so only in your minds. [*] They leave the definition of a "package" to the implementor, as physical packages do not always correspond to the logical package. For instance in debian, many software packages are split into subpackages. - -- 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 iD8DBQE8Rwg+fAeuFodNU5wRAmioAJ0XFEWmNMJ749xtyFESNuSViDRV+wCfSxi/ xc7FoHdSJFuKpWpphK3iGy8= =PyID -END PGP SIGNATURE-
KMail and GPG
Hello, I've generated a key with 3 different UID with GPG. I affected each one to an identity in KMail. When I sign my message, KMail always use the same identity for the three. Is it possible to have a key with three UID with KMail ? Thank you -- [EMAIL PROTECTED]
Re: [kde] setting an /opt precedent
"Eray Ozkural (exa)" <[EMAIL PROTECTED]> cum veritate scripsit: > The answer I got when I asked "Why isn't /opt used in Debian ?" has always > been "/opt violates Debian Policy". If you are talking about random add-on packages that is distributed from kde.org or whatever else, that would be fine, as long as it is independent from Debian. We, as Debian, do not use /opt. We reserve it for third party software. There might be a third party software which may want to install in /opt/kde We allow that to happen. Please read and understand the policy, and why we have a good reputation on not having touched /usr/local. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 05:09:54PM +0200, Eray Ozkural (exa) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 17 January 2002 16:21, Daniel Stone wrote: > > You might note the discussion on debian-kde of late, where Eray is > > attempting to set a precedent by installing KDE3 into /opt/kde3. Let me > > first disclose my viewpoint: I think this idea sucks, as you can clearly > > see from my postings. > > > > The answer I got when I asked "Why isn't /opt used in Debian ?" has always > been "/opt violates Debian Policy". > > However on James's message, I read the section and saw that there is no such > thing in neither the policy nor FHS. I'm only saying that installing packages > in /opt doesn't seem to violate the FHS in any way. As I explained in my > messages, "/opt violates Debian Policy" seems to depend on a certain > assumption that "add-on" means "non-free software supplied by third party > commercial vendors" whereas in the text of the FHS there is no such > implication. On the contrary it says distributions can install software in > /opt, just not touch a few reserved subdirs of /opt. > > However, using /opt may not be a good path to follow for most free software. > I understand that as well as you do, especially for software following GNU > Coding Standards it is absolutely unnecessary. > /opt could be used for all non-distribution software. Personally I prefer the BSD equivalent /usr/local. /opt is a bit too err... SysV-sounding :) for me. The same Solaris freewares are no more installed within /opt as in the past. So all 'local' software (commercial or not) can be installed under /usr/local, also sysadmin's scripts and programs. /me installs all additional (non-Debian,non-Solaris,etc) software under those dirs and hates to see other stuff installed there. They are mine! Keep your hands off :) -- Francesco P. Lovergine
Re: [kde] setting an /opt precedent
Il gio, 2002-01-17 alle 16:34, Eray Ozkural (exa) ha scritto: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 17 January 2002 17:22, Daniel Stone wrote: > > /opt is for "add-on" software. kde is not an "add-on". we package it as > > part of the distribution, it's not added on. > > That is a wrong reading of standard text. > > /opt -- Add-on application software packages > > There is a difference between system and application software. C++ library is > system software, while a desktop environment like KDE is application > software. System can continue functioning in the absence of such application > software that is optional, hence the expression "Add-on". oh, yeah. lets put about 90% of debian in /opt. > As stated in section 3.8, distributions can install software in /opt in > accordance with FHS. > > Moreover, this is an established practice as emphasized in FHS standard text. Debian *does*not*need* yet another place to install packages. lets /opt untouched for (free or non-free) external packages. /usr - system vendor, us. /opt - external vendors /usr/local - sysadmin is it that difficult to understand why this layout is optimal? -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] God is real. Unless declared integer. -- Anonymous FORTRAN programmer pgpc6fD6fifdM.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 17:36, Daniel Stone wrote: > > There are reserved directories, under which the distributions do not > > touch. /opt/bin is one of them, and it's a directory that the local admin > > manages. /opt/bin should be in $PATH I said, and /opt/lib in library > > search path. I said nothing about /opt//bin if you would care to > > notice. /opt/bin and /opt//bin serve different purposes. > > MY POINT EXACTLY!! > > /opt/bin could be in $PATH if you want, but who cares? We CANNOT touch > it! So what's your solution? Put /opt/kde3/bin in $PATH? Imagine how > large $PATH will grow if everyone follows our precedent. > > KDE is not that much of a special case. Excuse me? Supporting /opt properly in debian was a point I made in no relation to KDE packaging. I think you have missed it. 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 iD8DBQE8Ru+dfAeuFodNU5wRAs/oAKCV7jbRoaCakYMC5Pi3oArnDp8W4wCgmLSW fDljfvrU81DjoFsKUJSFeqU= =hQG4 -END PGP SIGNATURE-
Re: Fix for KDE source distributions
On Thursday 17 January 2002 3:11 pm, Eray Ozkural (exa) wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 17 January 2002 17:03, James Thorniley wrote: > > Hi, > > > > I've done a patch for the acinclude.m4.in file which defines how source > > distributions find the KDE install dirs that should make it work around > > the non standard layout in debian (see my earlier posts re: location of > > docs etc. someone has also mentioned the move of config files to > > /etc/kde2, which this should also work around). > > That's certainly not a good idea James... There is a utility to find those > dirs on a KDE installation, remember? Hi, I don't think I explained how the patch works well enough it *does not* hard code any directories into the configure system, in fact, it hard codes less. It uses the kde-config utility supplied to work out the correct directories to use. The standard acinclude.m4.in (that kdevelop gave me for my project, anyway), does not do this. Regards, James
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 17:22, Daniel Stone wrote: > /opt is for "add-on" software. kde is not an "add-on". we package it as > part of the distribution, it's not added on. That is a wrong reading of standard text. /opt -- Add-on application software packages There is a difference between system and application software. C++ library is system software, while a desktop environment like KDE is application software. System can continue functioning in the absence of such application software that is optional, hence the expression "Add-on". As stated in section 3.8, distributions can install software in /opt in accordance with FHS. Moreover, this is an established practice as emphasized in FHS standard text. Sincerely, - -- 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 iD8DBQE8Ru76fAeuFodNU5wRAndQAKCBeku05DBEg3Q5+ToNxv+qU/RE3ACfSqzD lB8hJ3pMTxNNFWlRhrC8Cds= =A9+P -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 05:27:22PM +0200, Eray Ozkural (exa) wrote: > Hi Daniel, > > I recommend you to read section 3.8 of FHS. Someone who talks so knowingly of > FHS should take the time to read it, too. I suggest you take basic comprehension classes. > On Thursday 17 January 2002 17:22, Daniel Stone wrote: > > > > > > Except that, it seems to be in "violation of FHS" to not support reserved > > > subdirs of /opt intended for local administrator's use, such as /opt/bin > > > and /opt/lib. They should exist on a default install, and binaries in > > > /opt/bin should be in $PATH, etc. > > > > And binaries in /opt/kde3/bin? And /opt/apache/bin? And ... you get the > > point. How large do you want $PATH to be? And before you can say > > "symlink", we can't screw around with /opt/bin, either. And providing > > one wrapper script for every binary is MESSY, and SUCKS imho. How many > > KDE binaries are there? The answer is: $toomany. > > There are reserved directories, under which the distributions do not touch. > /opt/bin is one of them, and it's a directory that the local admin manages. > /opt/bin should be in $PATH I said, and /opt/lib in library search path. I > said nothing about /opt//bin if you would care to notice. /opt/bin > and /opt//bin serve different purposes. MY POINT EXACTLY!! /opt/bin could be in $PATH if you want, but who cares? We CANNOT touch it! So what's your solution? Put /opt/kde3/bin in $PATH? Imagine how large $PATH will grow if everyone follows our precedent. KDE is not that much of a special case. -- Daniel Stone<[EMAIL PROTECTED]> -Evii- (opnotice/#linux/18@) I hereby vote DanielS as my choice for the new channel manager ;) -Lion-O- [Wall/#linux] /me kills evii -RelDrgn- i vote we shoot evii ;) -Evii- (opnotice/#linux/18@) Hey would be a great way to get rid of the lusers.. and regulars.. and ops.. ;) (editor's note: Evii was drunk at the time) pgpvsDpN2ALCi.pgp Description: PGP signature
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Daniel, I recommend you to read section 3.8 of FHS. Someone who talks so knowingly of FHS should take the time to read it, too. On Thursday 17 January 2002 17:22, Daniel Stone wrote: > > > > Except that, it seems to be in "violation of FHS" to not support reserved > > subdirs of /opt intended for local administrator's use, such as /opt/bin > > and /opt/lib. They should exist on a default install, and binaries in > > /opt/bin should be in $PATH, etc. > > And binaries in /opt/kde3/bin? And /opt/apache/bin? And ... you get the > point. How large do you want $PATH to be? And before you can say > "symlink", we can't screw around with /opt/bin, either. And providing > one wrapper script for every binary is MESSY, and SUCKS imho. How many > KDE binaries are there? The answer is: $toomany. > There are reserved directories, under which the distributions do not touch. /opt/bin is one of them, and it's a directory that the local admin manages. /opt/bin should be in $PATH I said, and /opt/lib in library search path. I said nothing about /opt//bin if you would care to notice. /opt/bin and /opt//bin serve different purposes. 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 iD8DBQE8Ru1afAeuFodNU5wRAraaAJ0SNGfqq78uvYscwW0n2QvzqnQV1ACfd7ZO bDr2FuQVpQzK2EQaJUq4Uyo= =YJ4d -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
On Thu, Jan 17, 2002 at 05:09:54PM +0200, Eray Ozkural (exa) wrote:
> On Thursday 17 January 2002 16:21, Daniel Stone wrote:
> > You might note the discussion on debian-kde of late, where Eray is
> > attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> > first disclose my viewpoint: I think this idea sucks, as you can clearly
> > see from my postings.
> >
>
> The answer I got when I asked "Why isn't /opt used in Debian ?" has always
> been "/opt violates Debian Policy".
I've explicitly stated my other reservations about /opt several times
when you say this, but you just don't get the point.
/opt sucks.
/opt has not been used by any other Debian package to date afaik.
/opt does not exist in a default debian installation, afaik.
/opt is for "add-on" software. kde is not an "add-on". we package it as
part of the distribution, it's not added on.
> However on James's message, I read the section and saw that there is no such
> thing in neither the policy nor FHS. I'm only saying that installing packages
> in /opt doesn't seem to violate the FHS in any way. As I explained in my
> messages, "/opt violates Debian Policy" seems to depend on a certain
> assumption that "add-on" means "non-free software supplied by third party
> commercial vendors" whereas in the text of the FHS there is no such
> implication. On the contrary it says distributions can install software in
> /opt, just not touch a few reserved subdirs of /opt.
Yes, you too can clutter /opt with one subdir per package! WHOO!
> However, using /opt may not be a good path to follow for most free software.
> I understand that as well as you do, especially for software following GNU
> Coding Standards it is absolutely unnecessary.
Yes. Absolutely.
> > My main concern is that we'll set a precedent here in Debian for this
> > sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> > fact I'm pretty sure it doesn't even exist on a default install.
> >
> > So, please read the thread and state your opinions. I know it's a KDE
> > issue, but I feel it affects Debian as a whole, since putting something
> > in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> > major precedent for Debian.
>
> Actually Red Hat doesn't do it that way. Red Hat for instance uses
> --prefix=/usr for their KDE packages in 7.2.
>
> SuSE uses /opt, and they claim to be FHS compliant of course. I haven't had
> the opportunity to examine either of the systems (I've never used a Red Hat
> or SuSE system), however that was what other KDE coders told me.
>
> One thing to discuss here would be whether FHS is right about that issue or
> not. So feel free to send patches to FHS :)
>
> Except that, it seems to be in "violation of FHS" to not support reserved
> subdirs of /opt intended for local administrator's use, such as /opt/bin and
> /opt/lib. They should exist on a default install, and binaries in /opt/bin
> should be in $PATH, etc.
And binaries in /opt/kde3/bin? And /opt/apache/bin? And ... you get the
point. How large do you want $PATH to be? And before you can say
"symlink", we can't screw around with /opt/bin, either. And providing
one wrapper script for every binary is MESSY, and SUCKS imho. How many
KDE binaries are there? The answer is: $toomany.
> Please send replies to debian-kde too, or Cc: me.
Please don't Cc: me on any Debian posts any more as I'm honestly not
interested.
--
Daniel Stone<[EMAIL PROTECTED]>
Subject: ssh: shit is fucked
pgpW59CxlEb8B.pgp
Description: PGP signature
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 17:10, Daniel Stone wrote: > > That IS an ugly hack. The only package I know of that does this is qt2, > because that's the way it works, and there's no non-trivial way to make > it use the Debian layout without breaking every assumption made. > ls /usr/lib/petsc There must be others, too. > My suggestion was this, which I did roughly with apache2: > if [ echo $i | egrep -i ^kde ]; then NEWNAME=`echo $i | sed -e > 's/^kde/kde3/;'` else NEWNAME=`echo $i | sed -e 's/$/3/;'` > This might not work, you might have to tell it at build time... > > I suggest you to at least implement: "/usr/share/kde3" under which all > > KDE3 ro arch indep data should go in such as "/usr/share/kde/icons". > > I have no beef with this. This is the sort of sane suggestion I wish > you'd come up with more frequently. I've always thought this should be > done, as /usr/share is just too cluttered. > OK. Agreed then. At last we have an agreement :) > > Second suggestion is to implement "/usr/lib/kde3" and append the path to > > /etc/ld.so.conf like the atlas package does. It's the nicest way to > > handle that large collection of libraries. > > ICK, NO. Hehe, you're such a Stone. That's an officially supported way of achieving this. There's no problem with it, it's just as good as putting them in /usr/lib. Just have a look at how packages such as libc5 and atlas handle this. I'm certain there are others, too. 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 iD8DBQE8RurifAeuFodNU5wRAm6AAKCZzFJ3ZsUirUGKxYM9yUv5oh7iEACgkRHG MN89TeVu3G6WAkFpVxnGKC4= =HZpD -END PGP SIGNATURE-
Re: Fix for KDE source distributions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 17:03, James Thorniley wrote: > Hi, > > I've done a patch for the acinclude.m4.in file which defines how source > distributions find the KDE install dirs that should make it work around the > non standard layout in debian (see my earlier posts re: location of docs > etc. someone has also mentioned the move of config files to /etc/kde2, > which this should also work around). That's certainly not a good idea James... There is a utility to find those dirs on a KDE installation, remember? 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 iD8DBQE8RumsfAeuFodNU5wRAl8xAJ4swy9jut72JnrcEr9tOe26Yc8kbQCeKp0Z 6oSfC0CXJRWiPW6aUHureu8= =LMSd -END PGP SIGNATURE-
Re: [kde] setting an /opt precedent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 17 January 2002 16:21, Daniel Stone wrote:
> You might note the discussion on debian-kde of late, where Eray is
> attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
> first disclose my viewpoint: I think this idea sucks, as you can clearly
> see from my postings.
>
The answer I got when I asked "Why isn't /opt used in Debian ?" has always
been "/opt violates Debian Policy".
However on James's message, I read the section and saw that there is no such
thing in neither the policy nor FHS. I'm only saying that installing packages
in /opt doesn't seem to violate the FHS in any way. As I explained in my
messages, "/opt violates Debian Policy" seems to depend on a certain
assumption that "add-on" means "non-free software supplied by third party
commercial vendors" whereas in the text of the FHS there is no such
implication. On the contrary it says distributions can install software in
/opt, just not touch a few reserved subdirs of /opt.
However, using /opt may not be a good path to follow for most free software.
I understand that as well as you do, especially for software following GNU
Coding Standards it is absolutely unnecessary.
> My main concern is that we'll set a precedent here in Debian for this
> sort of behaviour. AFAIK no Debian package has ever touched /opt; in
> fact I'm pretty sure it doesn't even exist on a default install.
>
> So, please read the thread and state your opinions. I know it's a KDE
> issue, but I feel it affects Debian as a whole, since putting something
> in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
> major precedent for Debian.
Actually Red Hat doesn't do it that way. Red Hat for instance uses
- --prefix=/usr for their KDE packages in 7.2.
SuSE uses /opt, and they claim to be FHS compliant of course. I haven't had
the opportunity to examine either of the systems (I've never used a Red Hat
or SuSE system), however that was what other KDE coders told me.
One thing to discuss here would be whether FHS is right about that issue or
not. So feel free to send patches to FHS :)
Except that, it seems to be in "violation of FHS" to not support reserved
subdirs of /opt intended for local administrator's use, such as /opt/bin and
/opt/lib. They should exist on a default install, and binaries in /opt/bin
should be in $PATH, etc.
Please send replies to debian-kde too, or Cc: me.
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
iD8DBQE8RulCfAeuFodNU5wRAk9vAKCPX8rS7CSc8dR9wRoT+AHyyyIJWACfeeRX
A54ZmkWG4PisvWD4IRg3j+s=
=lyhs
-END PGP SIGNATURE-
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
On Thu, Jan 17, 2002 at 04:57:33PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 16:12, Daniel Stone wrote: > > No. > > > > Your original complaint was about cluttering the namespace. With this > > solution, not only are you implementing TWO ugly hacks (the > > /usr/lib/kde3 prefix and /usr/bin symlinks), but the namespace stays > > "cluttered". > > /usr/lib/kde3 isn't an ugly hack. why, then large packages which have their > file hierarchies in /usr/lib/ implementing an ugly hack? that's not > the case... That IS an ugly hack. The only package I know of that does this is qt2, because that's the way it works, and there's no non-trivial way to make it use the Debian layout without breaking every assumption made. > /usr/bin symlinks doesn't seem very good to me either. another solution is to > write a wrapper script that prepends the required path (startkde3). > there should be a single entry point to using KDE3. that way, you can choose > running kde3 or not in the beginning (which is a good thing), KDE2 apps would > continue running the same way. Oh god, please no. > you would simply move the binaries to /usr/bin which would be the cleanest... > wait, you can't symlink or copy KDE3 binaries to /usr/bin anyway, if you want > to keep KDE2 and KDE3 together. Yes, you can use the autoconf trick to > prepend all binary names with "kde3_" but that's even worse. My suggestion was this, which I did roughly with apache2: if [ echo $i | egrep -i ^kde ]; then NEWNAME=`echo $i | sed -e 's/^kde/kde3/;'` else NEWNAME=`echo $i | sed -e 's/$/3/;'` > Chris, have you been able to provide a set of KDE3 packages that do not kill > KDE2? Not yet. > I suggest you to at least implement: "/usr/share/kde3" under which all KDE3 > ro arch indep data should go in such as "/usr/share/kde/icons". I have no beef with this. This is the sort of sane suggestion I wish you'd come up with more frequently. I've always thought this should be done, as /usr/share is just too cluttered. > Second suggestion is to implement "/usr/lib/kde3" and append the path to > /etc/ld.so.conf like the atlas package does. It's the nicest way to handle > that large collection of libraries. ICK, NO. -d -- Daniel Stone<[EMAIL PROTECTED]> i'm not so lonely that i need to install emacs pgpMyfcr864Hl.pgp Description: PGP signature
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 16:12, Daniel Stone wrote: > > No. > > Your original complaint was about cluttering the namespace. With this > solution, not only are you implementing TWO ugly hacks (the > /usr/lib/kde3 prefix and /usr/bin symlinks), but the namespace stays > "cluttered". /usr/lib/kde3 isn't an ugly hack. why, then large packages which have their file hierarchies in /usr/lib/ implementing an ugly hack? that's not the case... /usr/bin symlinks doesn't seem very good to me either. another solution is to write a wrapper script that prepends the required path (startkde3). there should be a single entry point to using KDE3. that way, you can choose running kde3 or not in the beginning (which is a good thing), KDE2 apps would continue running the same way. you would simply move the binaries to /usr/bin which would be the cleanest... wait, you can't symlink or copy KDE3 binaries to /usr/bin anyway, if you want to keep KDE2 and KDE3 together. Yes, you can use the autoconf trick to prepend all binary names with "kde3_" but that's even worse. Chris, have you been able to provide a set of KDE3 packages that do not kill KDE2? I suggest you to at least implement: "/usr/share/kde3" under which all KDE3 ro arch indep data should go in such as "/usr/share/kde/icons". Second suggestion is to implement "/usr/lib/kde3" and append the path to /etc/ld.so.conf like the atlas package does. It's the nicest way to handle that large collection of libraries. 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 iD8DBQE8RuZefAeuFodNU5wRAtDAAJ9nXACKx9d+xJ4kQHVcNSyeRHSDnQCgmmzw +fcsOOn+el4kWnMzpIlEZ/Q= =MZm0 -END PGP SIGNATURE-
Fix for KDE source distributions
Hi, I've done a patch for the acinclude.m4.in file which defines how source distributions find the KDE install dirs that should make it work around the non standard layout in debian (see my earlier posts re: location of docs etc. someone has also mentioned the move of config files to /etc/kde2, which this should also work around). I haven't attached the patch because I'm not sure how much interest there would be on this list. If you would like a copy either email me or get it from my project on sourceforge http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kcast/kcast/admin/acinclude.m4.in It's only been hacked internally, so it should work as a drop in replacement for most KDE source distributions (might be worth a try if you cant get a distribution to install properly, anyway). Note this patch is a little dodgy since I'm not very experienced with automake, I'm going to write to the kdevelop mailing list and see if anyone is interested in taking a look to check I haven't actually screwed it in any obvious way ;) If it turns out ok I will submit it to Stephan Kulow who appears to be the current maintainer so it might get included somewhere upstream, but I suspect it will be undergoing modifications for KDE3 so I don't know how it would fit in. Thanks James
Re: [kde] setting an /opt precedent
Il gio, 2002-01-17 alle 15:21, Daniel Stone ha scritto: > You might note the discussion on debian-kde of late, where Eray is > attempting to set a precedent by installing KDE3 into /opt/kde3. Let me > first disclose my viewpoint: I think this idea sucks, as you can clearly > see from my postings. > > My main concern is that we'll set a precedent here in Debian for this > sort of behaviour. AFAIK no Debian package has ever touched /opt; in > fact I'm pretty sure it doesn't even exist on a default install. 1. debian follows FHS as strictly as possible 2. FHS says that: 3.8 /opt : Add-on application software packages ... /opt is reserved for the installation of add-on application software packages. ... 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. my oppinion here is that is *much better* to ignore /opt and reserve it for _third_party_ packaged applications (i.e., if FooSoft packages the Bar application using .deb format, would be nice to have it install in /opt/bar and not pollute /usr namespace [reserved for the OS vendor, i.e., Debian]). debian developers should stay away from /opt. ciao, federico -- Federico Di Gregorio Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] The reverse side also has a reverse side. -- Japanese proverb pgpUcH6zbXF5X.pgp Description: PGP signature
[kde] setting an /opt precedent
You might note the discussion on debian-kde of late, where Eray is
attempting to set a precedent by installing KDE3 into /opt/kde3. Let me
first disclose my viewpoint: I think this idea sucks, as you can clearly
see from my postings.
My main concern is that we'll set a precedent here in Debian for this
sort of behaviour. AFAIK no Debian package has ever touched /opt; in
fact I'm pretty sure it doesn't even exist on a default install.
So, please read the thread and state your opinions. I know it's a KDE
issue, but I feel it affects Debian as a whole, since putting something
in /opt ("SuSE and RedHat do it, so it *must* be good!"), would set a
major precedent for Debian.
-d
--
Daniel Stone<[EMAIL PROTECTED]>
asuffield: you are about as helpful as a broomstick up the arse.
yes
pgptS7NtOyFLn.pgp
Description: PGP signature
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
On Thu, Jan 17, 2002 at 03:51:27PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 01:24, Eray Ozkural (exa) wrote: > > > > That's all that is needed! > > Something is left out. What do we do with binaries? I think binaries should > stay in /usr/lib/kde3/bin, and linked to /usr/bin. Maybe /usr/bin/X11 would > be an even better place. Would this be a good solution? No. Your original complaint was about cluttering the namespace. With this solution, not only are you implementing TWO ugly hacks (the /usr/lib/kde3 prefix and /usr/bin symlinks), but the namespace stays "cluttered". -- Daniel Stone<[EMAIL PROTECTED]> apt, karma dpkg dpkg has karma of 1 apt: '640K ought to be enough for anybody.' - Bill Gates, 1981 dpkg: bugger all, i dunno apt: The name is Baud..., James Baud ...but name is already something else... pgp7vW9jKZud5.pgp Description: 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/) > > > > 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]> aaronl, i have this site you should see... lemme guess, goatse.cx? how did you know! pgpC6uE8Cw2x4.pgp Description: PGP signature
Re: KDE filesystem structure
On Thu, Jan 17, 2002 at 03:43:51PM +0200, Eray Ozkural (exa) wrote: > On Thursday 17 January 2002 07:15, Daniel Stone wrote: > > > Therefore, a system that uses an efficient unified filesystem > > > > > implementation instead of a packaging system to keep track of file > ^^ > > > export > > PATH=$PATH:/opt/kde/bin:/opt/kde3/kin:/opt/qt/bin:/opt/apache/bin:/opt/apac > >he2/bin:/opt/koffice/bin:/opt/gcc/bin:... > > > > NO. > > By that I meant a filesystem that has "virtual" dirs, much like in Amiga and > BSD (IIRC). It was a tangential idea, but evidently it works much better than > messing around with a string variable. Give me a yell when all of Debian has this feature. -- Daniel Stone<[EMAIL PROTECTED]> no bod's kids are watching elmo... elmo's song pgp4Dm6eH2P8u.pgp Description: PGP signature
Re: Summary of KDE filesystem discussion
On Wed, Jan 16, 2002 at 11:19:25PM +0200, Jarno Elonen wrote: > * 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 Those people have a hard wired path in their mind from "virtual path name" to "physical directory on disk". They are plain wrong, and will need to adapt their partitioning practice and filesystem functionality to reality and technical elegance. Maybe GNU/Linux is not, but the GNU/Hurd is ready (at least principially[1]) to allow intelligent disk space management and still have everything in /bin. I would XFree86 to be moved to /usr/bin at least some day. In days where you can get a 120GB hard disk for 350 euro, I really don't see the need. The trend is to hide the differences between storage devices, not to make it visible to the user. Thanks, Marcus [1] You can't boot yet from a shadowed filesystem, and the shadowfs implementation is not yet ready for prime time. But all the ground has been cleared and cultivated. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 01:24, Eray Ozkural (exa) wrote: > > That's all that is needed! Something is left out. What do we do with binaries? I think binaries should stay in /usr/lib/kde3/bin, and linked to /usr/bin. Maybe /usr/bin/X11 would be an even better place. Would this be a good solution? 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 iD8DBQE8RtbffAeuFodNU5wRAsZfAJ9PzfU1lm1G+/6bFvXf8F0DWLW5TACcDSYe 7WffeMs8sQuzdYFwngxUZoY= =9BjM -END PGP SIGNATURE-
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/) > > 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: KDE filesystem structure
On Thursday 17 January 2002 07:15, Daniel Stone wrote: > > Therefore, a system that uses an efficient unified filesystem > > implementation instead of a packaging system to keep track of file ^^ > export > PATH=$PATH:/opt/kde/bin:/opt/kde3/kin:/opt/qt/bin:/opt/apache/bin:/opt/apac >he2/bin:/opt/koffice/bin:/opt/gcc/bin:... > > NO. By that I meant a filesystem that has "virtual" dirs, much like in Amiga and BSD (IIRC). It was a tangential idea, but evidently it works much better than messing around with a string variable. 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
Re: KDE filesystem structure
On Thu, Jan 17, 2002 at 12:45:36AM +0200, Eray Ozkural (exa) wrote:
> On Wednesday 16 January 2002 23:55, Daniel Stone wrote:
> >
> > 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?
> >
>
> Apache is beyond the scope of discussion I think.
No, not in the slightest. We are talking about setting a Debian-wide
precedent, which is why I urge you to take it to -devel.
> However, as you indicate, if FHS compliance requires that people should
> change their PATH variables to run software installed in /opt or use
> ridiculously long pathnames then it is clearly something that should be
> avoided. My feeling is that packages ought to be able to install front end
> files by linking into the /opt/bin, etc. However, that is discussion of the
> FHS and not discussion on debian KDE packages.
Well, it says "don't stuff around with /opt/{bin,lib,...}", I think
that's pretty clear.
> > 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.
>
> Of course I won't do any sort of change before there is some form of
> consensus. It's a small change, but without agreement it can't be done. Note
> that you are saying it is bad because it's a change to something old. :)
We need consensus from -devel, not just -kde.
> There are two choices KDE programmers favor:
> 1) Installing into /opt/kde{version}
> 2) Installing into /usr
>
> Debian does the latter, but... kde2 vs. kde3.
As I keep reminding you, KDE hackers are upstream, not Debian. They pump
out tarballs of an awesome desktop environment. We make it so you can
type "apt-get install kde", instead of building that stuff. I suggest we
keep this separation, unless coolo wants to take over the packaging
again.
--
Daniel Stone<[EMAIL PROTECTED]>
If Theo de Raadt patches a security hole in the woods and there's
no-one there to see him, will it still be fixed in OpenBSD three years ago?
pgprAM8kHm10p.pgp
Description: PGP signature
Re: kdm and xset?
> But I can't find where I'm suppose to put that command so it would get > run anytime kdm is run, > /etc/kde/kdm/Xsetup > or anytime when a wm is chosen. > you mean, when a session is started, right? .../Xsession greetings -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Nothing is fool-proof to a sufficiently talented fool.
filesystem discussion (my 2 cents)
Ok, having both (kde2 and kde3) in debian the both time might not be the best idea. Disadvantages: - quite some trouble regarding where the files should go .-) - would waste lots of diskspace on the mirrors. - Is it really needed? KDE3 supplies improved version of all kde core apps, and is normally stable on release date. So heres my suggestion: KDE3 is kept out of debian as long as it is really released. (KDE3 release, probably a little bit later to catch some hot cvs upstream fixes .-) ). The KDE3 moves into debian, and replaces KDE2, at least all the apps, that are allready ported to KDE3. For the other apps the kde2 kdelibs and kdebase-libs (probably some more) will stay in debian, als long as there are KDE2 apps not ported to KDE3. Same for the -dev packages, since it should still be possible to compile a KDE2 app and run it. This would cut the discussion above and would prevent a lot of trouble. Also we would get a hug from the mirror maintainers. Until the release of KDE calc could supply beta (KDE3 RC1) debs from an external apt source. (p.d.o). Here it could be considerable to use the --prefix=/opt/kde3 (optional package) as long as it stays external and then change the prefix to /usr if it gets close to release time, or from an apt source as replacement allready for the installed kde2, conflicting. Max P.S: before everybody who participated in the filesystemthread above and who wants to tells me that his/her idea is better, clear your mind a bit and thing about my idea .-). The discussion was in some parts just to emotional. P.P.S: I would especially like to hear calcs comment on this.
kde, woody and fonts
Hello I'm using kde on a woody powered computer. Since the last apt-get update, a few days ago, I've got a problem. The fonts selectable in kde are only a very small part of the X fonts avaible on my computer. In particular, I've no fixed font (a mess for konsole!!!) xlsfonts and xfontsel are OK, as well as gtk and gnome apps, wich all lists a great deal of fonts. I've tested to use or not the x font server xfs, to edit /etc/kde2/kde2.sh to comment or uncomment override. I'm runnig with a french localisation, but I don't think the iso-8859-1 default has anything to do with that (or?) Any help welcome. PS: I'm not a subscriber to the list. I will of course read the archives in a few days, but any direct reply in CC would be appreciated at [EMAIL PROTECTED] PS excuse my poor english. -- Debian powered computer
kdm and xset?
I'm currently using kdm from a newly installed debian system. However the mouse movements on it are much too slow, so I use 'xset m 6 6' to get the speed I need/want. But I can't find where I'm suppose to put that command so it would get run anytime kdm is run, or anytime when a wm is chosen. Suggestions? Thanks in advance.
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: KDE filesystem structure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi DanielS,
I wouldn't suggest those changes without thinking over how it would be done.
On Wednesday 16 January 2002 23:55, Daniel Stone wrote:
>
> 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?
>
Apache is beyond the scope of discussion I think.
If you hesitate to read FHS carefully, you'll see that those issues have all
been taken care of (somewhat).
The configuration goes to /etc/opt/. Front ends for packages,
binaries that the user can invoke from command line, can be linked to
/opt/bin. Or wait, is the FHS being a bit vague here?
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.
This is a serious ambiguity. Does this allow distributions to place symbolic
links to /opt/bin automatically I wonder. I must ask the FHS people. If this
can be clarified, there is absolutely no reason why /opt shouldn't be used in
debian (except "hysterical raisins" which I don't take to be that relevant).
However, as you indicate, if FHS compliance requires that people should
change their PATH variables to run software installed in /opt or use
ridiculously long pathnames then it is clearly something that should be
avoided. My feeling is that packages ought to be able to install front end
files by linking into the /opt/bin, etc. However, that is discussion of the
FHS and not discussion on debian KDE packages.
[snip]
>
> 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.
Of course I won't do any sort of change before there is some form of
consensus. It's a small change, but without agreement it can't be done. Note
that you are saying it is bad because it's a change to something old. :)
There are two choices KDE programmers favor:
1) Installing into /opt/kde{version}
2) Installing into /usr
Debian does the latter, but... kde2 vs. kde3.
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
iD8DBQE8RgKQfAeuFodNU5wRAha3AJ9CcFJtUQQulXVPGUw1+nqXt5U0YACfYVXw
z51tSVO/C38g1Q0wRFHq+mQ=
=JGH4
-END PGP SIGNATURE-
Why did I suggest /usr/lib/kde3 or /opt/kde3? (Re: What are Chris and Daniel actually going to do now?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 00:54, Oliver Johns wrote: > 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? I think my suggestion needs some clarification. What was the motivation for that? The reason is that Ivan's yet untested approach will not work well when users want to install KDE2 and KDE3 at the same time. In my approach, you can choose among KDE2 or KDE3 to your heart's content. Note that the only file conflicts will *not* happen among libraries, which is why you should install in a KDE prefix other than /usr. There are many files that conflict, from the ground up. And there is no easy solution except implementing my proposed approach. For keeping multiple versions of KDE, as agreed on by hackers on #kde (including the knows-it-all noatun developer Charles[*]), you need to install them to a specific location other than /usr. That simple. My suggestion clearly targets that. If we had only one major version of KDE at a time (which will never be the case), then there would be no need for such a change. When we have final KDE3 release, there will be a guess what: a development version which will bring the same problems over again. As of now, the decision primarily interests Chris. I ought to summarize my suggestion again: Make a /usr/lib/kde3 hierarchy. Under this hierarchy, move directories that do not belong there (according to the policy) to their appropriate locations, and symlink them in /usr/lib/kde3. /usr/lib/kde3/include -> /usr/include/kde3 /usr/lib/kde3/share -> /usr/share/kde3 (install manual pages to their correct locations) Add /usr/lib/kde3 to /etc/ld.so.conf That's all that is needed! Make all this with a very simple build script, and include that script in a generic debian kde package as before. Also, the proposed change does not affect any KDE2 user in anyway as it stands, so please don't be confused by what's being discussed. Regards, [*] I mean it, Charles is one guy who has wisdom. - -- 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 iD8DBQE8RgvGfAeuFodNU5wRAulRAJ9FLe9V1pfoa/f4KuYkRdWW9wch7ACfaj4d 2dm/w9uaWOzTYrZ35KrtjKo= =jNnb -END PGP SIGNATURE-
Re: What are Chris and Daniel actually going to do now?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 17 January 2002 00:54, Oliver Johns wrote: > 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. > Hmm. I haven't read that very carefully. After of course after the initial kde3 packages, it was seen that you had to move /usr/share/ cruft to /usr/share/kde/ similar to what I had suggested a loong time ago. Actually Ivan's suggestion is not too different from what I propose, but mine is more improved. There is something that I omitted; I will write it later. 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 iD8DBQE8RhgffAeuFodNU5wRArtjAKCAhhBT2FkqifrXkZ+utQOnaboEIwCfcRRD H2I2iPXKHEVW6hb1avw4cT0= =r1Ry -END PGP SIGNATURE-
