Ok, I checked the menuproxy patches in gtk; if the specified module is not found, the application will run, but it will spew a lot of warning messages to stderr. So we should probably find a better solution for that instead of unconditionally setting the variable.
Unnecessary; with the correct debhelper level, you can write this as:
debian/tmp/gtk2/usr/lib/
... and all of the contents will be installed to the correct directory. (Or if necessary: debian/tmp/gtk2/usr/lib/* /usr/lib)
> * Add common packages for xsession file
We don't need to create a new package for the file given that it's identical across architectures. Though we do still have to work out a way to get it identical across architectures which doesn't result in the regression mentioned above.
Ok, I checked the menuproxy patches in gtk; if the specified module is not found, the application will run, but it will spew a lot of warning messages to stderr. So we should probably find a better solution for that instead of unconditionally setting the variable.
--- appmenu- gtk-0.3. 92.orig/ debian/ appmenu- gtk.install. in gtk-0.3. 92/debian/ appmenu- gtk.install. in tmp/gtk2/ usr/lib/ ${DEB_HOST_ MULTIARCH} /* /usr/lib/ ${DEB_HOST_ MULTIARCH} /
+++ appmenu-
@@ -0,0 +1 @@
+debian/
Unnecessary; with the correct debhelper level, you can write this as:
debian/ tmp/gtk2/ usr/lib/
... and all of the contents will be installed to the correct directory. (Or if necessary: debian/ tmp/gtk2/ usr/lib/ * /usr/lib)
> * Add common packages for xsession file
We don't need to create a new package for the file given that it's identical across architectures. Though we do still have to work out a way to get it identical across architectures which doesn't result in the regression mentioned above.