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!
Reply to: