Bug 202448 - Review Request: gnome-sharp
Review Request: gnome-sharp
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-08-14 11:13 EDT by Alexander Larsson
Modified: 2013-01-09 20:30 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-21 03:14:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander Larsson 2006-08-14 11:13:13 EDT
Spec URL: http://www.gnome.org/~alexl/gnome-sharp.spec
SRPM URL: http://www.gnome.org/~alexl/gnome-sharp-2.15.0-1.fc6.src.rpm
The gtk-sharp2 package was split up upstream into two tarballs, gtk-sharp and gnome-sharp as part of getting accepted into the gnome bindings set. This is the split out package for gnome-sharp.
Comment 1 Alexander Larsson 2006-08-14 11:23:09 EDT
If you need to build this you first need:
Comment 2 Paul F. Johnson 2006-08-14 11:42:47 EDT
# Mono only availible on these:
ExclusiveArch: %ix86 x86_64 ppc ia64 armv4l sparc
# no mono on s390 for now: s390 s390x 

Is this really required now? I can only remember seeing it on FC packages - it
has certainly never been pulled up on anything in FE

How does this build in a non x86 based system. Unless something has changed,
this will try to install material to lib64 rather than %{_prefix}/lib so the
build won't work.

The way I have fixed this is to have

%define monodir %{_prefix}/lib

%configure --libdir=%{monodir}



I will try this out tonight on the x86_64 box and let you know what happens.
Comment 3 Alexander Larsson 2006-08-14 11:52:32 EDT
The exclusivearch is needed of course. Otherwise things break on the other arches.
FE doesn't build on any non-mono arch, so that doesn't matter.

I haven't tried on x86-64. Maybe it needs:
make install DESTDIR=$RPM_BUILD_ROOT GACUTIL_FLAGS="/package gtk-sharp /gacdir
%{_prefix}/lib /root ${RPM_BUILD_ROOT}%{_prefix}/lib"
that gtk-sharp2 has.
Comment 4 Jesse Keating 2006-08-14 14:33:43 EDT
This package does not follow the guidelines from

.pc file is not in -devel package
gacutil is not used to register dlls
no call to ldconfig for .so file placed in %{_libdir}/
Comment 5 Paul F. Johnson 2006-08-14 16:10:54 EDT
If this is for core, does it still need to follow the FE guides? (sorry if this
is a blindingly obviously question)

As to installing gtk-sharp2 : with *that* spec file? You gotta be joking!
Where's the -devel file? what is GACUTIL - it doesn't exist (gacutil does)!
Comment 6 Jesse Keating 2006-08-14 16:20:09 EDT
(In reply to comment #5)
> If this is for core, does it still need to follow the FE guides? (sorry if this
> is a blindingly obviously question)

Yes.  The packaging guidelines are for Fedora, ALL of Fedora.  Not just Extras
or Core.  There is ONE set of guidelines that applies to ALL of Fedora,
including Core.
Comment 7 Alexander Larsson 2006-08-15 05:21:51 EDT
I updated the spec and the srpms with new versions.

ldconfig is added.

We do use gacutils to install the dlls, but not in the strange way that the
packaging guidelines example show, its just called as a normal part of the
upstream makefiles. We do pass the GACUTIL_FLAGS to make to override some of the
flags passed to it though.

I also added the -devel packages, but I don't think this is a very good idea.
The packaging guidelines says its bad because it'll somehow pull in devel
packages in a non-devel install, but that is simply not true (it has no
dependencies). Instead we duplicate all the package metadata for a 900 byte
package, bloating the install. Furthemore, having a -devel package means the
distro compose will pull in the 32bit version of the packages into the 64bit
distro, reinstating the yum update multilib conflict we solved this week.
Comment 8 Jesse Keating 2006-08-15 10:35:24 EDT
Alex, if the guidelines don't make sense, PLEASE PLEASE help us to make them
better.  Mono is one of those things that leave most of us scratching our heads
and trying to make sense of it.

The -devel package is to prevent development files being packaged in the main
package.  We've gone over this before, users may want to develop 32bit mono
software on a x86_64 host.  If mono isn't arch specific, then why aren't the
packages noarch?  I don't believe we "solved" anything last week, the headers
from the 32bit package and the 64bit package shouldn't conflict.  If they do,
the package needs to be fixed, not just avoided to sweep the problem under the rug.

if you wish to discuss the guidelines, please send mail to
Comment 9 Alexander Larsson 2006-08-18 08:50:26 EDT
I replaced the specfile with a new version that will not have multilib
conflicts. However, its part of a large package update i'm working on, so it
won't build with whats in FC6 now, so I didn't upgrade the SRPMS. However, its
basically just the old version with a patch added and prefix/lib changed to libdir.

Comment 10 Jesse Keating 2006-08-18 09:30:19 EDT
The devel package needs a Requires: pkgconfig since it contains a .pc file AND
puts it in the pkgconfig owned directory.

Other than that I think this is passible.  Approving so you can build the stack,
the whole mono stack is in flux and I understand that.  As we fix it more we
should revisit the guidelines to make sure they are kept in line with reality.

Please close when you've built into rawhide.
Comment 11 Paul F. Johnson 2006-08-20 06:05:34 EDT
There is a problem. I'm trying to build against gtk-sharp2 (which provides
gnome-sharp-2.0.pc). When running through mock, it complains that said
gnome-sharp-2.0.pc file is missing (or more accurately, it's not installed).

This has only happened since the push to the -2 release on the 19th Aug.
Comment 12 Alexander Larsson 2006-08-21 03:14:09 EDT
gtk-sharp2 is not providing gnome-sharp-2.0.pc. gnome-sharp-devel is.

Note You need to log in before you can comment on or make changes to this bug.