Remove the post-install/pkg-install, since gnomehier is taking care of
it.
devel/gnomevfs2
Add pkg-install and pkg-deinstall to restore libgnome's gconf key if
libgnome's .schemas exists. This fix the plist complained by pointyhat.
Why restore libgnome's gconf key during the installtion if it exists?
Because, libgnome always depend on gnomevfs2 so make sure the libgnome
is still in the top when we either reinstall or upgrade gnomevfs2.
misc/gnomehier
Remove the etc/gconf/gconf.xml.defaults/*, since the gconftool is
taking care of it. ie: GCONF_SCHEMAS
x11/libgnome
Add pkg-deinstall to restore gnomevfs2's gconf key if gnomevfs2's
schemas exists. This fix the plist complained by pointyhat. Also, this
is a real fix for the weird keyboard problem when you uninstall
libgnome without reinstall it.
Bump the PORTREVISION in all of four ports above to fix everything with gconf
keys stuff for plist. Those have been tested in the MarcusCom CVS, GNOME
tinderbox, and my tinderbox.
- remove x11-fm/xfce4-fm-icons misc/xfce4-panel-themes (obsoleted by that update)
- take maintainership of x11-wm/xfce4-session [1]
- bump PORTREVISION of all plugins because they need to be linked against the new xfce4 libs
Approved by: maintainer [1]
in any order:
- add the X11 lib path to ld.so.conf in the linux base port
- (re)generate the ld.so.cache file in the linux base port too
- don't change the ld.so.conf in the linux X11 port
At deinstall time the linux base port may still complain about a changed
ld.so.cache file. A clean way to solve this would be to use ("@unexec" and
"@exec") in the plist. Since the plist is autogenerated this would need
some little magic in the plist generation or we have to switch to a static
plist. Delay the decission about how to handle this until we know when/how
to update to a more recent linux base port.
really convinced that gnomesu belongs in here anyway, esp. seeing as how
it's a part of gnomesystemmonitor (and hence gnome2-fifth-toe) in GNOME 2.9/10.
Does two unrelated things:
1) add linker flag to fix build [untested]
2) fix startup script [tested]
Whether 1) will work I have no idea. On my own machine,
everything works all right, and the errorlogs are
confusing. 2) is needed.
PR: ports/76171
Submitted by: Tobias Roth <ports@fsck.ch>
