Re: pkg-kde: commit - rev 90 - in trunk/packages/kdelibs/debian: . dh-make
On Tuesday 06 April 2004 19:18, Dominique Devriese wrote:
>
> calc, scroll to the bottom :)
>
> Christopher Martin writes:
>
> >> > If there is a preferred place, then this might be worth
> >> > mentioning in Packaging.txt as well.
> >>
> >> AIUI, Packaging.txt is about packaging a normal, well-behaving kde
> >> app. These use the kde build system, and as such, should
> >> automatically choose the right location, no ?
>
> > Hmmm, I've built packages (3rd party/extragear stuff) that, by
> > default, use either. oKle - applnk. Gwenview -
> > applications/kde. Those using applnk may be in need of an update,
> > either upstream or in the packaging, certainly, but for whatever
> > reason plenty of apps still do use applnk (K3b and kopete, for
> > instance), and may not bother to change since everything still
> > appears to be working fine.
>
> The Kopete developers consciously decided to not use the new dir,
> because they still support KDE 3.1. I'm not sure about the rest. In
> any case, if you encounter a package that uses applnk, that didn't
> consciously decide to do so, then it's most probably a bug in the
> Makefile.am. For example, in August, someone committed this change to
> kdeedu/kig/kig/Makefile.am:
> diff -u -r1.23 -r1.24
> --- Makefile.am 27 Jun 2003 12:26:56 -0000 1.23
> +++ Makefile.am 29 Aug 2003 19:59:44 -0000 1.24
> @@ -27,8 +27,7 @@
> kig_LDADD = $(LIB_KPARTS)
>
> # this is where the desktop file will go
> -shelldesktopdir = $(kde_appsdir)/Edutainment/Mathematics
> -shelldesktop_DATA = kig.desktop
> +xdg_apps_DATA = kig.desktop
>
> # this is where the shell's XML-GUI resource file goes
> shellrcdir = $(kde_datadir)/kig
> The upstream authors should do something similar ( and make sure they
> have a recent admin/ dir, so that xdg_appsdir is defined, of course ).
.. and make sure the desktop file has a Categories= entry. Because
that whats used AFAIU to put the app in a (sub)menu.
http://www.freedesktop.org/standards/menu-spec/menu-spec-0.8.html
http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html
Achim
>
> > Thus a small mention in Packaging.txt might help to nudge packagers
> > (especially new packagers) towards the correct location, in case
> > their sources still default to applnk, for whatever reason.
>
> Agreed, care to write the patch, perhaps ?
>
> > Perhaps also the /u/s/doc/kdelibs4-dev/dh-make/debiandirs should add
> > the following:
> > export kde_appsdir=/usr/share/applications/kde
>
> No, this would be wrong.
>
> > The only problem with this is that apps that had hitherto created a
> > subdirectory in /u/s/applnk (like Multimedia, or Graphics) would now
> > do the same in /u/s/applications/kde...
>
> Indeed.
>
> > One final thing. Packaging.txt currently contains an elaborate
> > description of how to take the kdelibs4-dev "debianrules" script,
> > place it in MYPACKAGE_SRCDIR/debian/ and convert it, using perl,
> > into the debian/debiandirs file which then sets crucial
> > variables. However, kdelibs4-dev doesn't provide debianrules
> > anymore, but debiandirs directly (in the dh-make directory), so
> > unless I'm mistaken there's no need for any perl kung-fu.
>
> > All I've been doing is copying the
> > /u/s/doc/kdelibs4-dev/dh-make/debiandirs file into
> > MYPACKAGE_SRCDIR/debian/ and then adding:
>
> > -include debian/debiandirs
>
> > in debian/rules before any targets are defined, and it works
> > well.
>
> > Am I doing something wrong, or can the Packaging.txt
> > instructions be simplified?
>
> Well, I agree with you that either debianrules should be installed
> instead of debiandirs, or Packaging.txt should be adapted. I'm not
> certain what calc wanted to do, but installing debianrules instead of
> debiandirs seems like the best solution to me personally. Anyway,
> calc, please shed some light on this !
>
> cheers
> domi
>
>
> --
> To UNSUBSCRIBE, email to debian-qt-kde-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
--
To me vi is Zen. To use vi is to practice zen. Every command is
a koan. Profound to the user, unintelligible to the uninitiated.
You discover truth everytime you use it.
-- reddy@lion.austin.ibm.com
Reply to: