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 <dstone@trinity.unimelb.edu.au> Developer, Trinity College, University of Melbourne
Attachment:
pgp9lul0BORUa.pgp
Description: PGP signature