4:58 p.m.
Hi,
MD-debugger-mdb is currently broken for rawhide. I've tried many ways to
get it to build and have finally asked for help from the the md mailing
list. The big problem is that we're using a system wide Mono.Cecil
rather than individual packages having their own version of Mono.Cecil.
Here's the conversation followed by a request from me...
8-->
On Wed, Dec 23, 2009 at 4:14 PM, Paul <paul(a)all-the-johnsons.co.uk>
wrote:
I've got MD-2.2 installed from Fedora rawhide and am trying to
build
the
MD debugger plugin. Problem is that it's looking for Mono.Cecil
in the
MD addins.
With Fedora, we use a system wide Mono.Cecil instead of having a pile
of
them around the place.
We use a local copy of Cecil because Cecil API is (was?) not
guaranteed to be stable and therefor the library is *supposed* to be
bundled with apps. This also allows us to rely on the exact behaviour
of the version we ship. By upgrading MD's Cecil to one it has not been
tested with, Fedora is potentially exposing their users to bugs that
we will be unable to reproduce and fix.
See http://www.mono-project.com/Cecil#Using_Cecil
<--8
Given this, should we change the approach we currently have for using
the system wide Mono.Cecil and allow the likes of MD to ship with it's
own version of Mono.Cecil?
Mono.Cecil is not added into GAC so having different versions of
Mono.Cecil for different applications should not cause conflicts.
"Should" is being used in it's lightest sense!
TTFN
Paul
P.S. Going off until Boxing Day now, so Merry Christmas to you all!
--
Sie können mich aufreizen und wirklich heiß machen!
9:55 a.m.
Paul wrote:
Given this, should we change the approach we currently have for
using
the system wide Mono.Cecil and allow the likes of MD to ship with it's
own version of Mono.Cecil?
No, we should patch the broken packages to work with the current Mono.Cecil.
And upstream deserves a beating for this attitude. :-/ Why am I not
surprised this is coming from the M$-loving Mono community?
In any case, if you do think an exception should be granted, this will have
to go through FESCo. But I doubt we will approve it, at least not if you
don't provide evidence that somebody competent in C# tried to patch
MonoDebugger to work with the new Mono.Cecil and failed due to some
unsurmountable obstacle. If none of you Mono SIG folks is fluent in C#, then
that's a problem that needs solving first of all.
Kevin Kofler
4:41 p.m.
Hi,
No, we should patch the broken packages to work with the current
Mono.Cecil.
And upstream deserves a beating for this attitude. :-/ Why am I not
surprised this is coming from the M$-loving Mono community?
I quite agree - there should be a universal mono.cecil.
In any case, if you do think an exception should be granted, this
will
have
to go through FESCo. But I doubt we will approve it, at least not if
you
don't provide evidence that somebody competent in C# tried to patch
MonoDebugger to work with the new Mono.Cecil and failed due to some
unsurmountable obstacle. If none of you Mono SIG folks is fluent in
C#, then
that's a problem that needs solving first of all.
MD itself works fine with Mono.Cecil as provided by other packages. The
problem is MD also copies Mono.Cecil to %{_libdir}/monodevelop/bin
which is what is being picked up on when -pkg:monodevelop is referenced
in the make file. It's not a problem with MD or Mono.Cecil really...
Oh well. I'll look at it (again) on the 28th.
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
11:40 a.m.
No, we should patch the broken packages to work with the current
Mono.Cecil.
And upstream deserves a beating for this attitude. :-/ Why am I not
surprised this is coming from the M$-loving Mono community?
Shouldn't Fedora take upstream's design into account? It's their
software, after all. And doesn't Java work in a similar way?
You can't expect everyone to change their software design to work for
Fedora, even if it has disadvantages.
12:04 a.m.
Jud Craft wrote:
Shouldn't Fedora take upstream's design into account?
It's their
software, after all.
It's our policy not to bundle system libraries. We're not the only ones,
Debian also has such a policy. Bundling libraries in applications sucks in a
distribution, the library which is part of the distribution should be used.
An additional problem is that the bundled .dlls are generally bundled as
binaries. Software in Fedora must be built from source. (And there too,
Debian also has such a policy.)
And doesn't Java work in a similar way?
Yes, unfortunately, bundling .jars is commonplace in upstream Java software,
we always rm -f all the bundled .jar files in %prep and we even have a
scriptlet snippet which runs find over the build tree to delete all bundled
.jar files. All .jar files MUST be built from source as separate packages.
You can't expect everyone to change their software design to work
for
Fedora, even if it has disadvantages.
We do expect that, sorry. Bundling libraries is not a solution, fixing the
library not to break its ABI/API every couple days is.
It just plain sucks to ship several different versions of the same library
in a distribution.
Kevin Kofler
6:47 a.m.
Hi,
> You can't expect everyone to change their software design to
work
for
> Fedora, even if it has disadvantages.
We do expect that, sorry. Bundling libraries is not a solution, fixing
the library not to break its ABI/API every couple days is.
Here I have to agree with you Kevin. Mono.Cecil is a pain, but it's the
only one in Mono which does change between packages. I don't understand
why.
As it stands, the fix was easy; change monodevelop so that it doesn't
add mono.cecil to the list that it provides and add it in by itself.
It's not a fix upstream will listen to (as aren't the 64 bit lib fixes -
don't ask, I've been trying for ages to get them to accept them).
I'm going to have a go at building the other monodevelop plugins over
the next week and get them into rawhide.... Assuming I still can by
then ;-p
TTFN
Paul
--
Sie können mich aufreizen und wirklich heiß machen!
5226
days inactive
5237
days old
6 comments
3 participants
participants (3)
-
Jud Craft -
Kevin Kofler -
Paul F. Johnson