Bugzilla – Bug 116196
gtksourceview-sharp-2_0 package is full of extraneous crap
Last modified: 2005-09-21 20:25:50 UTC
gtksourceview-sharp-2_0-0.10-9 installs the following files that have nothing to do with sharp source viewing: /usr/share/gapi-2.0/art-api.xml /usr/share/gapi-2.0/atk-api.xml /usr/share/gapi-2.0/gda-api.xml /usr/share/gapi-2.0/gdk-api.xml /usr/share/gapi-2.0/glade-api.xml /usr/share/gapi-2.0/gnome-api.xml /usr/share/gapi-2.0/gnome-vfs-api.xml /usr/share/gapi-2.0/gnomedb-api.xml /usr/share/gapi-2.0/gtk-api.xml /usr/share/gapi-2.0/gtkhtml-api.xml /usr/share/gapi-2.0/gtksourceview-api.xml /usr/share/gapi-2.0/pango-api.xml /usr/share/gapi-2.0/rsvg-api.xml /usr/share/gapi-2.0/vte-api.xml /usr/share/pkgconfig/alsa.pc /usr/share/pkgconfig/art-sharp-2.0.pc /usr/share/pkgconfig/art-sharp.pc /usr/share/pkgconfig/audiofile.pc /usr/share/pkgconfig/cairo.pc /usr/share/pkgconfig/com_err.pc /usr/share/pkgconfig/esound.pc /usr/share/pkgconfig/fontconfig.pc /usr/share/pkgconfig/freetype2.pc /usr/share/pkgconfig/gapi-2.0.pc /usr/share/pkgconfig/gapi.pc /usr/share/pkgconfig/gconf-sharp-2.0.pc /usr/share/pkgconfig/gconf-sharp.pc /usr/share/pkgconfig/gda-sharp-2.0.pc /usr/share/pkgconfig/gda-sharp.pc /usr/share/pkgconfig/glade-sharp-2.0.pc /usr/share/pkgconfig/glade-sharp.pc /usr/share/pkgconfig/glitz-glx.pc /usr/share/pkgconfig/glitz.pc /usr/share/pkgconfig/gnome-sharp-2.0.pc /usr/share/pkgconfig/gnome-sharp.pc /usr/share/pkgconfig/gnome-vfs-sharp-2.0.pc /usr/share/pkgconfig/gnomedb-sharp-2.0.pc /usr/share/pkgconfig/gnomedb-sharp.pc /usr/share/pkgconfig/gnutls-extra.pc /usr/share/pkgconfig/gnutls.pc /usr/share/pkgconfig/gtk-dotnet-2.0.pc /usr/share/pkgconfig/gtk-sharp-2.0.pc /usr/share/pkgconfig/gtk-sharp.pc /usr/share/pkgconfig/gtkhtml-sharp-2.0.pc /usr/share/pkgconfig/gtkhtml-sharp.pc /usr/share/pkgconfig/gtksourceview-sharp-2.0.pc /usr/share/pkgconfig/libart-2.0.pc /usr/share/pkgconfig/libpixman.pc /usr/share/pkgconfig/libpng.pc /usr/share/pkgconfig/libpng12.pc /usr/share/pkgconfig/libxml-2.0.pc /usr/share/pkgconfig/mint.pc /usr/share/pkgconfig/mono-nunit.pc /usr/share/pkgconfig/mono.pc /usr/share/pkgconfig/monodoc.pc /usr/share/pkgconfig/openssl.pc /usr/share/pkgconfig/resmgr.pc /usr/share/pkgconfig/rsvg-sharp-2.0.pc /usr/share/pkgconfig/rsvg-sharp.pc /usr/share/pkgconfig/ss.pc /usr/share/pkgconfig/vte-sharp-2.0.pc /usr/share/pkgconfig/vte-sharp.pc /usr/share/pkgconfig/xcomposite.pc /usr/share/pkgconfig/xcursor.pc /usr/share/pkgconfig/xdamage.pc /usr/share/pkgconfig/xevie.pc /usr/share/pkgconfig/xfixes.pc /usr/share/pkgconfig/xft.pc /usr/share/pkgconfig/xrender.pc Actually, these files: /usr/share/gapi-2.0/gtksourceview-api.xml /usr/share/pkgconfig/gtksourceview-sharp-2.0.pc are almost legit: they belong in /usr/lib though, not /usr/share
A fix has been submitted to autobuild. SuSE has a policy to put .pc files in /usr/share/pkgconfig instead of /usr/lib/pkgconfig
> SuSE has a policy to put .pc files in /usr/share/pkgconfig instead of > /usr/lib/pkgconfig That violates the FHS. From "man hier": /usr/share This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS. but .pc files are architecture-specific. Most blatantly, i586 .pc files will have lots of references to ${prefix}/lib, and x86_64 .pc files will have lots of references to ${prefix}/lib64
That's a very good point. Maybe in SuSE 11 all the custom .pc packaging changes will be reverted? Dunno...
noarch packages can have pkgconfig files as well, that's why these live in /usr/share. like for this one, where the pkgconfig file only points to a mono dll, that will always live below /usr/lib pkgconfig itself should only see /usr/%_lib/pkgconfig and /usr/share/pkgconfig. you are correct, that a pkgconfig file that refers to /usr/%_lib needs to be installed in /usr/%_lib/pkgconfig, but this one does not, as it points to a mono dll, that is not lib/lib64 specific. the erroneously packaged files were caused by the package _not_ using BuildRoot together with using a filelist with wildcards. (we were lucky this did not list a plain / .... )
reopen, because package needs to use BuildRoot (and the specfile should probably have a "# norootforbuild" as well).
Thanks for the BuildRoot suggestion. I wasn't sure what the problem was. This has been checked into autobuild.