inconsistency between sources at Fedora and upstream

[Christian Krause]

Hi,

Sorry for the lengthy mail, but I have observed something strange in our
mono packages: some of the tarballs we use in Fedora for packaging
differ from upstream:


During the last days I've searched a bug in f-spot where it sometimes
crashed with really weird backtraces like this (Fedora 10, mono 2.2):

ERROR:mini-exceptions.c:768:get_exception_catch_class: assertion failed:
(class->generic_class->container_class == method_container_class)
Stacktrace:

  at (wrapper managed-to-native)
System.Reflection.MonoMethod.InternalInvoke
(object,object[],System.Exception&) <0x00004>
  at (wrapper managed-to-native)
System.Reflection.MonoMethod.InternalInvoke
(object,object[],System.Exception&) <0xffffffff>2


I've found some upstream bug reports about the problem:
https://bugzilla.novell.com/show_bug.cgi?id=459285 and they claimed that
it got fixed in mono 2.2.

Currently, F10 uses mono-core-2.2-2.fc10.i386
I've checked out the corresponding tag (mono-2_2-2_fc10) and did a "make
local" which retrieved the tarball as it is in Fedora's packaging system:

md5sum mono-2.2.tar.bz2
a311545a0003f1a599297d57e4e27916  mono-2.2.tar.bz2

cat sources
a311545a0003f1a599297d57e4e27916  mono-2.2.tar.bz2

Then I've downloaded the official 2.2 tarball as it is linked on mono's
web page: http://ftp.novell.com/pub/mono/sources/mono/mono-2.2.tar.bz2

md5sum mono-2.2.tar.bz2
da147e24d14a73d8ad52775dd4a3d165  mono-2.2.tar.bz2

The (unified) diff between both mono versions is around 500kByte and the
upstream version also contains the claimed bug fix.


I have seen the same problem with mono-tools:
dc96a311a8fed1a3807fed92a99b6cf8  mono-tools-2.4.2.tar.bz2-upstream
49252ede8bec6e0b244f2a34712a067e  mono-tools-2.4.2.tar.bz2-fedora


If I read the changelogs correctly (here mono-tools latest version
update: "- Bump to 2.4.2 preview 1") then we've packaged previews of
official mono releases which unfortunately use the same name of the
tarball as the official release. I suggest if we package previews, then
we have to use the correct version/release scheme for pre-release packages:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

For mono-2.2 the spec file doesn't mention that a pre-release was packaged.


I'm convinced that not marking the pre-releases as such is highly risky:
 It is not obvious when you just look at the NVR itself and so the
chance is quite high that we stick to the pre-releases even in the
stable Fedora releases and miss so important bug fixes from upstream.


If it is OK with you, I'd like to do the following:


1. I'll just fix mono-tools (devel).


2. Regarding mono in F10: F10 is already in deep maintenance mode and so
 I believe we should _not_ update mono in F10 to 2.4 although the spec
files are already updated. But if there is not strong reason to do it,
we should do only critical bug fixes now to mono 2.2.

But I would also suggest to update F10's mono package to the official
2.2 release since it would solve problems as I was looking for at the
beginning and most likely it will contain also some more bug fixes from
upstream.

Since I'd like to get this bug fixed in F10 as fast as possible, I'd
like to volunteer to do it (if somebody could approve my commit
permissions ;-) ).



3. If I see it in other packages where I can commit and if there is
already an official release, I'll just update them too. If I'm not sure,
I'd ask for clarification on the list.


Does this sound acceptable to all you?


Best regards,
Christian