Re: Mono.Cecil monodevelop-debugger-mdb
That was definitely informative. Thanks for the explanations. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono.Cecil monodevelop-debugger-mdb
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! signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono.Cecil monodevelop-debugger-mdb
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. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Mono.Cecil monodevelop-debugger-mdb
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 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
