|
Bugzilla – Full Text Bug Listing |
| Summary: | gtksourceview-sharp-2_0 package is full of extraneous crap | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Dan Winship <danw> |
| Component: | Mono | Assignee: | Wade Berrier <wberrier> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | aj, ro |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dan Winship
2005-09-09 17:23:51 UTC
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. |