Hamish Moffatt wrote: > > At the risk of starting another flamewar, providing a KDE > package that installs in /opt is an obvious violation of debian > policy, which I assume is why Andreas does his own. Although > Andreas encourages us not to get the KDE people off-side, > sometimes it wouldn't hurt if the KDE people would try > not to piss us off either. >
There's a non-sense here. A package that installs in /opt is __not__ an "obvious violation" of debian policy, because debian policy doesn't say that "someone" _can't_ install in /opt . Our actual problem with /opt is that it is not "mentioned" in the FSSTND (but is allegated as a draft). But it is part of FHS-2.0, which we will implement after hamm's release (and discuss now), so it _will_ become actual policy in a close future. What will be /opt for Debian? I don't know, but the latest debate tell that we reserve use of /opt to "third parties" packaging their things for use on Debian systems. Therefore KDE people can legitimally use /opt (and I think that we should "mandate" and "force" third parties to install __out__ of /usr , which _is_ reserved to OS vendor). So what is your purpose in saying that > "the KDE people would try not to piss us off either" ? I also don't understand which problems Andreas found with their packaging decision. I haven't seen their packages (nor those from Andreas), but I think that, if correctly built, both packages should work the same way for users. And finding libraries is job for ld.so not for users. I suppose that if there are problems, they are packaging bugs. But if KDE packages has chose to install _only_ under /opt/kde (as some braindamaged producer already does), without providing installer scripts, then I think that debian (Andreas, for example) could/should make a kde-installer package that puts symlinks, wrappers, calls menu, ldconfig and all what is needed to let kde installation transparent for users. Installer packages aren't reserved for commercial packages, but can even be used for poorly-assembled ".deb" packages on which we have no control. No need to repackage everything. IMHO, my 10 penniƤ. Fabrizio -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E > Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]