Better KDEDIRS default ( was Re: Debian KDE 3 packages using a different kde_htmldir )
Dominique Devriese writes: domi Daniel Stone writes: Daniel On Tue, May 13, 2003 at 08:09:11PM +0100, David Pye wrote: While perhaps related to debian, and packaging, I'd like to add that third party KDE-based apps also seem unable to locate other files, such as .ui files, which locate themselves in /usr/local/kde/share/apps/appname. Daniel *sigh*, this isn't anything to do with the packages. export Daniel KDEDIRS=/usr:/usr/local. KDE has no clue that you've Daniel installed JuK to /usr/local, so you're going to have to tell Daniel it, if you decide to split your KDE installation over two Daniel prefixes. domi Why can't the packages just set KDEDIRS ( or the corresponding domi option ) to /usr/:/usr/local:/usr/local/kde, so that users domi won't have to deal with problems like the above ? This question seems to have gotten lost in the discussion about the kde_htmldir thing.. What are your opinions on this, why not apply the following patch ? Index: kstandarddirs.cpp === RCS file: /home/kde/kdelibs/kdecore/kstandarddirs.cpp,v retrieving revision 1.158 diff -u -b -r1.158 kstandarddirs.cpp --- kstandarddirs.cpp 19 May 2003 11:04:25 - 1.158 +++ kstandarddirs.cpp 19 May 2003 13:35:24 - @@ -1018,6 +1018,9 @@ } kdedirList.append(KDEDIR); +kdedirList.append( /usr/local ); +kdedirList.append( /usr/local/kde ); + #ifdef __KDE_EXECPREFIX QString execPrefix(__KDE_EXECPREFIX); if (execPrefix!=NONE) This makes it so that users won't have to mess with their KDEDIRS variable, which is something that they don't figure out for themselves most of the time.. thanks domi -- Q: Why did Menachem Begin invade Lebanon? A: To impress Jodie Foster.
Re: Debian KDE 3 packages using a different kde_htmldir
On Wed, May 14, 2003 at 10:40:56PM +0200, Dominique Devriese wrote: Paul Cupis writes: Paul On Wednesday 14 May 2003 14:41, Dominique Devriese Paul [EMAIL PROTECTED] wrote: No, that's not the problem. The problem is in the patch kdelibs.dirs.patch that only Debian applies. It makes it such that for any given prefix ( whether it is /usr, /usr/local or /usr/local/kde doesn't matter ), it expects the documentation to be in $prefix/share/doc/kde/HTML/ instead of $prefix/share/doc/HTML. This is purely Debian's fault, and it doesn't happen on SuSE because they don't mess with this.. Sorry I came in so late, I was finishing up at uni. At this point does it even make sense for it to be called /HTML? Only a few files in the tree are even html, almost all are either docbook or png files. Perhaps rename it to share/doc/kde/khelpcenter or even just share/doc/khelpcenter since all those docs are only used through it (right?). Also I have a gripe about KStandardDirs in general. It forces me to put crappy /usr/share/config fixup symlink to /etc/kde3 in Debian since it is based off --prefix. IMHO it should use the kderc file like the other function (forgot which) does. Having any directories hardcoded into the source file when kderc file exists is very bad, especially since it seems it doesn't even attempt to use the kderc file in KStandardDirs. Because of this I have to patch up for the html dir, cgi-bin dir, and config dir (by putting a symlink in). Perhaps the source file relating to this could be a kstandarddirs.cpp.in that gets its dirs filled in at setup time via configure. Even if the issue with /etc/kde3 and the others get resolved we still have the manually set KDEDIRS when you install into multiple places issue. I am not sure how gnome does it, but I believe that with it you can install into /usr/local (please correct me if I am wrong) without having to manually change things and pretty much every other application works that way as well. Someone probably should look into how they manage to make it work, and devise a way to make it possible for KDE as well. Thanks, Chris
Re: Debian KDE 3 packages using a different kde_htmldir
On Wed, May 14, 2003 at 08:41:00AM +0200, Dominique Devriese wrote: tell your users to use the option to ./configure, you mean, I guess, which is why I don't like this option too much.. Do you think there is any way to make ./configure auto-detect this ? Could perhaps debianrules get another output target that would be usable in a shell, and ./configure could source this if it detects it's on a debian system ? The best solution that I can come up with is fix the things in my other email I just sent to the list and also change the documentation dir default and config dir default to something saner. ;) Hint /usr/share/config is a FHS violation... Otherwise have kde-config provide all paths that are used so that the configure scripts can find the right location. Actually doing both of the above might be a good idea. Chris FHS 2.1 4. The /usr Hierarchy /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various hosts running FHS-compliant and should not be written to. **Any information that is host-specific or varies with time is stored elsewhere.**
Re: Debian KDE 3 packages using a different kde_htmldir
Ralf Nolden writes: Ralf On Freitag, 16. Mai 2003 10:57, Chris Cheney wrote: On Wed, May 14, 2003 at 08:41:00AM +0200, Dominique Devriese wrote: tell your users to use the option to ./configure, you mean, I guess, which is why I don't like this option too much.. Do you think there is any way to make ./configure auto-detect this ? Could perhaps debianrules get another output target that would be usable in a shell, and ./configure could source this if it detects it's on a debian system ? For reference, I sent a patch to Daniel Stone that adds this target, and he told me he would be committing this. However, Stephan Kulow told me he would not put any distribution-specific code in acinclude.m4.in, so it doesn't really help.. The best solution that I can come up with is fix the things in my other email I just sent to the list and also change the documentation dir default and config dir default to something saner. ;) Hint /usr/share/config is a FHS violation... Otherwise have kde-config provide all paths that are used so that the configure scripts can find the right location. Actually doing both of the above might be a good idea. Ralf Please mind what you're doing there - if I understand you Ralf correctly. It will have a *deep* impact with little noticable Ralf difference to the user but to all KDE apps that are already Ralf compiled the way they are now. Yes, I think this problem is a problem for whole of KDE. Maybe we should try to make the change in KDE, however this would probably have to wait for KDE 4 then, since it would not be easy to sanitize the paths stuff while keeping backward compatibility. Changing stuff in Debian-specific patches only creates a different set of annoying compatibility problems, especially for third party source packages, as you can see from the recent discussion about the problems caused by kdelibs.dirs.patch. Ralf I wouldn't change anything on the current setup - you can Ralf install the packages but you can also, alongside, compile your Ralf own CVS and applications into /usr/local (did that here and it Ralf works fine) Agreed. However, I think that we should maybe try to start a discussion on kde-core-devel about the KDE install paths policy, so that it might get fixed in KDE 4. cheers domi -- Fine day for friends. So-so day for you.
Re: Debian KDE 3 packages using a different kde_htmldir
On Fri, May 16, 2003 at 02:23:06PM +0200, Dominique Devriese wrote: Ralf I wouldn't change anything on the current setup - you can Ralf install the packages but you can also, alongside, compile your Ralf own CVS and applications into /usr/local (did that here and it Ralf works fine) Agreed. However, I think that we should maybe try to start a discussion on kde-core-devel about the KDE install paths policy, so that it might get fixed in KDE 4. It would also be nice to get rid of some of the dlopen crap in KDE4. Right now there are kparts that are being used as both a library and a kpart at the same time so the .la file is required to be in /usr/lib. Also getting rid of the degenerate shared objects for regular binaries now that prelink exists would be nice. Another thing that needs to be done is the creation of an arts plugin directory, right now all its plugins are being dumped directly into /usr/lib. There are probably other issues with KDE that I am just forgetting at the moment. Chris
Re: Debian KDE 3 packages using a different kde_htmldir
On Fri, May 16, 2003 at 02:23:06PM +0200, Dominique Devriese wrote: For reference, I sent a patch to Daniel Stone that adds this target, and he told me he would be committing this. However, Stephan Kulow told me he would not put any distribution-specific code in acinclude.m4.in, so it doesn't really help.. I've got two debianrules patches, that both support exporting shell-type variables. I'll be committing today. Yes, I think this problem is a problem for whole of KDE. Maybe we should try to make the change in KDE, however this would probably have to wait for KDE 4 then, since it would not be easy to sanitize the paths stuff while keeping backward compatibility. *nod*. However, it's never too early to start a discussion (somewhere like -core-devel). Changing stuff in Debian-specific patches only creates a different set of annoying compatibility problems, especially for third party source packages, as you can see from the recent discussion about the problems caused by kdelibs.dirs.patch. Oh, for sure. I don't think anyone was ever suggesting to make this radical a change in our packages. Agreed. However, I think that we should maybe try to start a discussion on kde-core-devel about the KDE install paths policy, so that it might get fixed in KDE 4. Agreed; I'll start drafting an email. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpocSRk6K96A.pgp Description: PGP signature
Re: Debian KDE 3 packages using a different kde_htmldir
Daniel Stone writes: Daniel On Tue, May 13, 2003 at 07:39:02PM +0200, Dominique Devriese Daniel wrote: The only Debian kdelibs patch, kdelibs/debian/patches/kdelibs.dirs.diff changes KGlobals to only look for html resources that are named $prefix/share/doc/kde/HTML ( and changes some cgi-bin search path too.. ). Daniel And fair enough, too; looking in /usr/share/doc/HTML could Daniel pick up any random documentation. You misunderstood me, I meant that it looked in $prefix/share/doc/kde/HTML/$thepackageathand/ This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. Daniel You could say that installing to /usr breaks all third-party Daniel KDE apps; it's just a matter of how you install it. This is another problem, indeed. Why don't the Debian KDE packages set the prefixes to /usr:/usr/local:/usr/local/kde, so that installing third party source packages goes as easy as possible ? So my question is: Wtf is this patch intended to fix, and why does it not make sure that people installing third party kde apps from source can still read the documentation.. Daniel /usr/share/doc/HTML is documentation for the package called Daniel 'HTML'. If everyone put their documentation in there, it Daniel would be an utter mess. I don't think that just putting kde stuff in a different place solves anything, since in the HTML dir are only kde packages' documentation, and such the mess remains, it's just split in half. Daniel It's just another sad legacy of KDE assuming there will Daniel never be anything else in its prefix. :\ Yeah, I heard how this was a problem for the Debian packages trying to install things in the right places.. Basically, I see three ways to fix this problem: 1 remove the patch. This would probably also mean some work to make the docs install in the proper place again.. 2 fix the patch, to make sure it *also* searches in the old place 3 keep the patch, and fix the kde build system to make sure that a 3rd party source package properly detects where it should install its documentation. Daniel I vote for 3 - just use the option to ./configure. tell your users to use the option to ./configure, you mean, I guess, which is why I don't like this option too much.. Do you think there is any way to make ./configure auto-detect this ? Could perhaps debianrules get another output target that would be usable in a shell, and ./configure could source this if it detects it's on a debian system ? cheers domi -- You will be given a post of trust and responsibility.
Re: Debian KDE 3 packages using a different kde_htmldir
On Wed, May 14, 2003 at 08:41:00AM +0200, Dominique Devriese wrote: Daniel Stone writes: Daniel On Tue, May 13, 2003 at 07:39:02PM +0200, Dominique Devriese Daniel wrote: The only Debian kdelibs patch, kdelibs/debian/patches/kdelibs.dirs.diff changes KGlobals to only look for html resources that are named $prefix/share/doc/kde/HTML ( and changes some cgi-bin search path too.. ). Daniel And fair enough, too; looking in /usr/share/doc/HTML could Daniel pick up any random documentation. You misunderstood me, I meant that it looked in $prefix/share/doc/kde/HTML/$thepackageathand/ Yes. Which is what it should do. This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. Daniel You could say that installing to /usr breaks all third-party Daniel KDE apps; it's just a matter of how you install it. This is another problem, indeed. Why don't the Debian KDE packages set the prefixes to /usr:/usr/local:/usr/local/kde, so that installing third party source packages goes as easy as possible ? Because you should be using packages where possible, anyway? So my question is: Wtf is this patch intended to fix, and why does it not make sure that people installing third party kde apps from source can still read the documentation.. Daniel /usr/share/doc/HTML is documentation for the package called Daniel 'HTML'. If everyone put their documentation in there, it Daniel would be an utter mess. I don't think that just putting kde stuff in a different place solves anything, since in the HTML dir are only kde packages' documentation, and such the mess remains, it's just split in half. That's my point! KDE documentation should remain in /usr/share/doc/kde/HTML, where it belongs. Daniel I vote for 3 - just use the option to ./configure. tell your users to use the option to ./configure, you mean, I guess, which is why I don't like this option too much.. If you have that many Debian users, wouldn't it be easier to just make packages? Do you think there is any way to make ./configure auto-detect this ? Could perhaps debianrules get another output target that would be usable in a shell, and ./configure could source this if it detects it's on a debian system ? Well, you could source debianrules, and use $(kde_options) or whatever. Detecting a Debian system is wrong and broken. I run a Debian system, but run HEAD, and all my stuff is in /opt/qt3 and /opt/kde3. -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp6yNBRBLLkk.pgp Description: PGP signature
Re: Debian KDE 3 packages using a different kde_htmldir
Daniel Stone writes: This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. Daniel You could say that installing to /usr breaks all third-party Daniel KDE apps; it's just a matter of how you install it. This is another problem, indeed. Why don't the Debian KDE packages set the prefixes to /usr:/usr/local:/usr/local/kde, so that installing third party source packages goes as easy as possible ? Daniel Because you should be using packages where possible, anyway? Well, you said it yourself, where possible, you should use packages. In many cases, KDE users want to install things where packages are not available, or too old. I think that it's a distribution's job to make it easy for the user whatever he wants to do. And I don't see how you can say that installing KDE programs from source is not important enough to make a trivial fix in the KDE packages.. Daniel I vote for 3 - just use the option to ./configure. tell your users to use the option to ./configure, you mean, I guess, which is why I don't like this option too much.. Daniel If you have that many Debian users, wouldn't it be easier to Daniel just make packages? 1 I would have to make three different packages, one for stable, testing and unstable. This is more work than I'm willing to do atm. 2 I don't have that many Debian users, but every one of them seems to complain about stuff not working.. Do you think there is any way to make ./configure auto-detect this ? Could perhaps debianrules get another output target that would be usable in a shell, and ./configure could source this if it detects it's on a debian system ? Daniel Well, you could source debianrules, and use $(kde_options) Daniel or whatever. Detecting a Debian system is wrong and Daniel broken. I run a Debian system, but run HEAD, and all my Daniel stuff is in /opt/qt3 and /opt/kde3. As I said, I have tried to source the output of debianrules echodirs in three different shells: zsh: domi: ~/src/kdeedu/admin $(./debianrules echodirs) export: not an identifier: -p bash: domi: ~/src/kdeedu/admin $(./debianrules echodirs) bash: export: `-p': not a valid identifier bash: export: `-c': not a valid identifier bash: export: `-m': not a valid identifier bash: export: `644': not a valid identifier snip sh: domi: ~/src/kdeedu/admin . /tmp/echodirsout sh: export: `-p': not a valid identifier sh: export: `-c': not a valid identifier sh: export: `-m': not a valid identifier sh: export: `644': not a valid identifier sh: kde_prefix: command not found sh: kde_bindir: command not found snip Is this a separate problem, and can I fix it by just putting quote's around the assignments ? Why would detecting a Debian system, and changing the default values if it is one, be wrong ? You can still change the values yourself if you have a non-default setup.. cheers domi -- You'll never be the man your mother was!
Re: Debian KDE 3 packages using a different kde_htmldir
On Mittwoch, 14. Mai 2003 08:34, Dominique Devriese wrote: Ralf Nolden writes: I know, I've been playing around with creating a Debian package, but this is not what I'm talking about.. Ralf export kde_htmldir=/usr/share/doc/kde/HTML I suppose I have to tell all Debian users to export this before configuring then ? Then please turn to debian-devel and ask there to change their standards to allow a global HTML directory in /usr/share/doc. cheers domi -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpgnpfhYHHRk.pgp Description: signature
Re: Debian KDE 3 packages using a different kde_htmldir
Ralf Nolden writes: Ralf export kde_htmldir=/usr/share/doc/kde/HTML I suppose I have to tell all Debian users to export this before configuring then ? Ralf Then please turn to debian-devel and ask there to change their Ralf standards to allow a global HTML directory in /usr/share/doc. Hmm.. I see.. Still, I don't see why it wouldn't be possible for the kde build system to change the defaults for the dirs on debian ? Do you think this would be a good idea ? Ralf You have to do that because /usr is used as a prefix. With Ralf e.g. SuSE using /opt/kde3 as a prefix this problem doesn't Ralf happen. It wouldn't happen either if kde was installed into Ralf /usr/local/kde or /usr/kde. Of course then you're running Ralf into all sorts of different problems. No, that's not the problem. The problem is in the patch kdelibs.dirs.patch that only Debian applies. It makes it such that for any given prefix ( whether it is /usr, /usr/local or /usr/local/kde doesn't matter ), it expects the documentation to be in $prefix/share/doc/kde/HTML/ instead of $prefix/share/doc/HTML. This is purely Debian's fault, and it doesn't happen on SuSE because they don't mess with this.. I understand though that Debian has had to move their documentation to this location, and has had to make sure that the KDE KStandardDirs still found it by applying the patch, however, what imho should have been done, in order to keep third party apps working, was that the KStandardDirs patch should have made sure that the old location ( $prefix/share/doc/HTML ) was also searched.. However, the damage is probably already done, since all previous KDE versions in Debian have had the patch applied, so I'm going to make a patch for the KDE build system that makes it install HTML documentation in $prefix/share/doc/kde/HTML by default.. cheers domi -- Grief can take care of itself; but to get the full value of a joy you must have somebody to divide it with. -- Mark Twain
Re: Debian KDE 3 packages using a different kde_htmldir
Dominique Devriese writes:
domi However, the damage is probably already done, since all
domi previous KDE versions in Debian have had the patch applied, so
domi I'm going to make a patch for the KDE build system that makes
domi it install HTML documentation in $prefix/share/doc/kde/HTML by
domi default..
Hi again,
I'm going to send this patch to coolo.. It changes the default
documentation install path for HTML documentation to
$prefix/share/doc/kde/HTML, for a Debian installation on which
kdelibs4 is installed..
Would you agree this is a good solution ?
( sorry if I may have sounded a bit annoyed during the discussion, I'm
just trying to fix this, since it's quite annoying for a third party
app developer.. )
cheers
domi
Index: acinclude.m4.in
===
RCS file: /home/kde/kde-common/admin/acinclude.m4.in,v
retrieving revision 2.364
diff -u -r2.364 acinclude.m4.in
--- acinclude.m4.in 14 May 2003 13:27:14 - 2.364
+++ acinclude.m4.in 14 May 2003 14:44:36 -
@@ -421,7 +421,15 @@
if test $1 = default; then
if test -z $kde_htmldir; then
-kde_htmldir='\${prefix}/share/doc/HTML'
+if test -f /etc/debian_version; then
+ if dpkg -s kdelibs4 | grep Status | grep not-installed 21 /dev/null; then
+ kde_htmldir='\${prefix}/share/doc/HTML';
+ else
+ kde_htmldir='\${prefix}/share/doc/kde/HTML'
+ fi
+else
+ kde_htmldir='\${prefix}/share/doc/HTML'
+fi
fi
if test -z $kde_appsdir; then
kde_appsdir='\${prefix}/share/applnk'
--
You will step on the night soil of many countries.
Re: Debian KDE 3 packages using a different kde_htmldir
On Wednesday 14 May 2003 08:47, Dominique Devriese wrote: Hmm.. rereading your email, why can't the packages just set KDEDIRS ( or the corresponding option ) to /usr/:/usr/local:/usr/local/kde, so that users won't have to deal with problems like the above ? Agree, it's possible to install any app on linux anywhere, except kde programs for which it seems impossible to find where they are installed. I don't see any apparent reason for that. -- Frank Van Dammehttp://www.openstandaarden.be ~~~~ Click a link for instructions according to your operating system. If you don't know what an operating system is, click Windows.
Re: Debian KDE 3 packages using a different kde_htmldir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 14 May 2003 14:41, Dominique Devriese [EMAIL PROTECTED] wrote: No, that's not the problem. The problem is in the patch kdelibs.dirs.patch that only Debian applies. It makes it such that for any given prefix ( whether it is /usr, /usr/local or /usr/local/kde doesn't matter ), it expects the documentation to be in $prefix/share/doc/kde/HTML/ instead of $prefix/share/doc/HTML. This is purely Debian's fault, and it doesn't happen on SuSE because they don't mess with this.. I understand though that Debian has had to move their documentation to this location, and has had to make sure that the KDE KStandardDirs still found it by applying the patch, however, what imho should have been done, in order to keep third party apps working, was that the KStandardDirs patch should have made sure that the old location ( $prefix/share/doc/HTML ) was also searched.. Sorry to join this late... On Debian systems, all files under /usr/share/doc/HTML are generated and owned my the dhelp system (package 'dhelp'). As such, if KDE (or any ther) program installed files there, they wuold be wiped out the next time dhelp regenerated the directory. As such, it does not make sense for third-party docs to be installed there, as they would be deleted without notice to the user. However, the damage is probably already done, since all previous KDE versions in Debian have had the patch applied, so I'm going to make a patch for the KDE build system that makes it install HTML documentation in $prefix/share/doc/kde/HTML by default.. I don't think that Debian will change to put KDE docs in /usr/share/doc/HTML, even if that remains upstreams position. The easiest was for users to install packages from source and still get their documentation would be for them to pass kde_htmldir=/usr/share/doc/kde/HTML to their make install line: make install kde_htmldir=/usr/share/doc/kde/HTML On Wednesday 14 May 2003 15:52, Dominique Devriese [EMAIL PROTECTED] wrote: Hi again, I'm going to send this patch to coolo.. It changes the default documentation install path for HTML documentation to $prefix/share/doc/kde/HTML, for a Debian installation on which kdelibs4 is installed.. Would you agree this is a good solution ? On first glance, this seems okay. The other option, as I think you've said is for the KDE3 packages to add /usr/local/share/doc/HTML to their search package for KDE documenation (etc), which I don't think is a good idea. Paul Cupis - -- [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+wpFKIzuKV+SHX/kRAlNYAJ9Ef1vQZnNbOTZLV5zqZgEDOQOWiACfYKrJ gI4ojV+ZApgOvYBc02Ygeuc= =DOYh -END PGP SIGNATURE-
Re: Debian KDE 3 packages using a different kde_htmldir
Paul Cupis writes: Paul On Wednesday 14 May 2003 14:41, Dominique Devriese Paul [EMAIL PROTECTED] wrote: No, that's not the problem. The problem is in the patch kdelibs.dirs.patch that only Debian applies. It makes it such that for any given prefix ( whether it is /usr, /usr/local or /usr/local/kde doesn't matter ), it expects the documentation to be in $prefix/share/doc/kde/HTML/ instead of $prefix/share/doc/HTML. This is purely Debian's fault, and it doesn't happen on SuSE because they don't mess with this.. Paul Sorry to join this late... Paul On Debian systems, all files under /usr/share/doc/HTML are Paul generated and owned my the dhelp system (package 'dhelp'). As Paul such, if KDE (or any ther) program installed files there, they Paul wuold be wiped out the next time dhelp regenerated the Paul directory. right.. Paul As such, it does not make sense for third-party docs to be Paul installed there, as they would be deleted without notice to Paul the user. err.. yes, neither before or after the patch would this be the case, I think.. Only without the patch and if the user configures with --prefix=/usr would this happen. With the patch, this should never happen.. However, the damage is probably already done, since all previous KDE versions in Debian have had the patch applied, so I'm going to make a patch for the KDE build system that makes it install HTML documentation in $prefix/share/doc/kde/HTML by default.. Paul I don't think that Debian will change to put KDE docs in Paul /usr/share/doc/HTML, even if that remains upstreams Paul position. The easiest was for users to install packages from Paul source and still get their documentation would be for them to Paul pass kde_htmldir=/usr/share/doc/kde/HTML to their make install Paul line: Paul make install kde_htmldir=/usr/share/doc/kde/HTML yes, the patch makes this the default on Debian systems. Hi again, I'm going to send this patch to coolo.. It changes the default documentation install path for HTML documentation to $prefix/share/doc/kde/HTML, for a Debian installation on which kdelibs4 is installed.. Would you agree this is a good solution ? Paul On first glance, this seems okay. The other option, as I think Paul you've said is for the KDE3 packages to add Paul /usr/local/share/doc/HTML to their search package for KDE Paul documenation (etc), which I don't think is a good idea. Yes, in the mean time, I've sent the patch to coolo, I'll let the list what he replies... cheers domi -- You will forget that you ever knew me.
Re: Debian KDE 3 packages using a different kde_htmldir
Hi, While perhaps related to debian, and packaging, I'd like to add that third party KDE-based apps also seem unable to locate other files, such as .ui files, which locate themselves in /usr/local/kde/share/apps/appname. Even though compiled locally, the apps themselves can't then find these files. I had to move these to my own ~/.kde/share/apps/appname as the other one doesn't appear to be searched properly. (JuK, for those interested, is broken if compiled on Debian with these packages, and segfaults when trying to play ANYTHING, until I fixed it as described above) Cheers, David On Tuesday 13 May 2003 18:39, Dominique Devriese wrote: Hi, ( i'm not sure if this is the debian kde development list, or if it's more of a user list, so please refer me to the right place if this isn't the place for this ) The only Debian kdelibs patch, kdelibs/debian/patches/kdelibs.dirs.diff changes KGlobals to only look for html resources that are named $prefix/share/doc/kde/HTML ( and changes some cgi-bin search path too.. ). This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. So my question is: Wtf is this patch intended to fix, and why does it not make sure that people installing third party kde apps from source can still read the documentation.. Basically, I see three ways to fix this problem: 1 remove the patch. This would probably also mean some work to make the docs install in the proper place again.. 2 fix the patch, to make sure it *also* searches in the old place 3 keep the patch, and fix the kde build system to make sure that a 3rd party source package properly detects where it should install its documentation. What do you think ? cheers domi -- Conscience doth make cowards of us all. -- Shakespeare
Re: Debian KDE 3 packages using a different kde_htmldir
On Dienstag, 13. Mai 2003 19:39, Dominique Devriese wrote: Hi, ( i'm not sure if this is the debian kde development list, or if it's more of a user list, so please refer me to the right place if this isn't the place for this ) The only Debian kdelibs patch, kdelibs/debian/patches/kdelibs.dirs.diff changes KGlobals to only look for html resources that are named $prefix/share/doc/kde/HTML ( and changes some cgi-bin search path too.. ). This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. So my question is: Wtf is this patch intended to fix, and why does it not make sure that people installing third party kde apps from source can still read the documentation.. They can. They just have to source the file debianrules in the admin directory of their sourcepackage they compile. You can also just easily use dh-make to package the source directly so you can uninstall it if you don't like it. apt-get install dh-make dh_make -t /usr/share/doc/kdelibs4-dev/dh-make That will add a debian dir to the sourcepackage that works with the current kdelibs and exports all values needed: export kde_htmldir=/usr/share/doc/kde/HTML :-) Ralf Basically, I see three ways to fix this problem: 1 remove the patch. This would probably also mean some work to make the docs install in the proper place again.. 2 fix the patch, to make sure it *also* searches in the old place 3 keep the patch, and fix the kde build system to make sure that a 3rd party source package properly detects where it should install its documentation. What do you think ? cheers domi -- Conscience doth make cowards of us all. -- Shakespeare -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpH6K9Hi1zZU.pgp Description: signature
Re: Debian KDE 3 packages using a different kde_htmldir
On Tue, May 13, 2003 at 08:09:11PM +0100, David Pye wrote: While perhaps related to debian, and packaging, I'd like to add that third party KDE-based apps also seem unable to locate other files, such as .ui files, which locate themselves in /usr/local/kde/share/apps/appname. Even though compiled locally, the apps themselves can't then find these files. I had to move these to my own ~/.kde/share/apps/appname as the other one doesn't appear to be searched properly. (JuK, for those interested, is broken if compiled on Debian with these packages, and segfaults when trying to play ANYTHING, until I fixed it as described above) *sigh*, this isn't anything to do with the packages. export KDEDIRS=/usr:/usr/local. KDE has no clue that you've installed JuK to /usr/local, so you're going to have to tell it, if you decide to split your KDE installation over two prefixes. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpx2X0wKHvOt.pgp Description: PGP signature
Re: Debian KDE 3 packages using a different kde_htmldir
On Tue, May 13, 2003 at 07:39:02PM +0200, Dominique Devriese wrote: The only Debian kdelibs patch, kdelibs/debian/patches/kdelibs.dirs.diff changes KGlobals to only look for html resources that are named $prefix/share/doc/kde/HTML ( and changes some cgi-bin search path too.. ). And fair enough, too; looking in /usr/share/doc/HTML could pick up any random documentation. This patch breaks the documentation of all third party KDE applications, since these packages ( at least those that use the standard KDE build system to install docs ), install their documentation in $prefix/share/doc/HTML, and this is never searched by kio_help, even when KDEDIRS is set properly. You could say that installing to /usr breaks all third-party KDE apps; it's just a matter of how you install it. So my question is: Wtf is this patch intended to fix, and why does it not make sure that people installing third party kde apps from source can still read the documentation.. /usr/share/doc/HTML is documentation for the package called 'HTML'. If everyone put their documentation in there, it would be an utter mess. It's just another sad legacy of KDE assuming there will never be anything else in its prefix. :\ Basically, I see three ways to fix this problem: 1 remove the patch. This would probably also mean some work to make the docs install in the proper place again.. 2 fix the patch, to make sure it *also* searches in the old place 3 keep the patch, and fix the kde build system to make sure that a 3rd party source package properly detects where it should install its documentation. I vote for 3 - just use the option to ./configure. -- Daniel Stone [EMAIL PROTECTED] [EMAIL PROTECTED] KDE: Konquering a desktop near you - http://www.kde.org pgpcKoDVgNDZZ.pgp Description: PGP signature
