depending on dh-make (was: different kde_htmldir)
On Wed, 14 May 2003, Daniel Stone wrote:
> On Wed, May 14, 2003 at 08:41:00AM +0200, Dominique Devriese wrote:
> > Daniel Stone writes:
> > 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?
KDE should recognize stuff under /usr/local.
<more reasons to support /usr/local ootb>
Afaict there is no place for an admin to make global mods to
KDE. I have some-editor.desktop files I'd love to be used in
preference to the ones KDE supplies; putting them under /usr gets them
overwritten next upgrade, using kappfinder gets everyone their own
copy in .kde (and the sysadmin loses control of the contents).
It seems pretty typical of large multi-piece software packages to have
a mechanism for including both admin and user supplied components
(e.g.: emacs, tex, python, ocaml, octave, ruby, ...)
</more reasons to support /usr/local ootb>
> > >> 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.
The dir belongs to dhelp; if KDE registered its docs there would be
links in the HTML/*/index.html files.
> > 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.
(aesthetics aside) I don't see why they should remain or belong in any
particular place, compatibility is just a symlink or reference away,
right. KDE should look for stuff in user (.kde), local (/usr/local &
/opt) then system (/usr) space.
> > 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
> > 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.
I think the dh-make template should get its own package (placing it
under /usr/share/debhelper/dh_make perhaps), and build-depend on
Building a debian-kde package: `dh_make -t... && debian/rules...',
or perhaps a more automated `kdepackage' (think kpackage) command.
3rd party developers could be given, and instructed on how to edit up,
an overlay template... making the build command:
dh_make -t... && dh_make -o... && debian/rules...
downside: a more complex "kdepackage" is getting attractive
What I would like to do (but would need to actually learn PERL first)
is to break out the code which determines the values of the
substitution targets in the templates, and place it into the template
directory. i.e., putting #AUTHOR# in a template would trigger the
<path-to-template>/#AUTHOR# (or whatever name would work :-) script,
whose output would be used as the substitution.
The result would have dh-make managing the application of templates,
template authors determining their own destiny (.spec template(s)?),
everyone using dh-made src automatically gets packages tailored to
their system, developers get a flexible and relatively painless method
of enforcing standards...
...which is really what the whole `stuff not being found' problem is