[Mono-dev] dependency conflicts on rpm based distros
Hello, I think the current way of defining dependencies in rpm files for mono is broken. The scripts, which actually do it is part of the mono distribution and affects every rpm based distro. (This is for mono 2.0 but the script is the same for 2.4) I don't find any good resources about library versioning and compatibility only these: http://mono-project.com/Mono:Versioning http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html But in Section 3.2.1: - Each of the libraries in the GAC has an assembly version number that consists of 4 parts (major, minor, build and revision number) It is general practice and recommended by Microsoft that a library is ABI compatible when only the build and revision number change and the major and minor number stay the same. The automatic generated provides/requires during rpmbuild do _not_ follow this general practice an this leads to ugly dependency problems. (On rpm updates) (See the example) Background == Its not easy to describe, but it has to do with the scripts: * mono-find-provides * mono-find-requires which are called during rpmbuild time. I think these scripts work too strict. read on. For example: The interaction on the package banshee-1 and taglib-sharp. In OpenSuSE 11.1 is an update from taglib-sharp from 2.0.3.0 to 2.0.3.2. If I start rpm update I get: Processing Dependency: mono(taglib-sharp) = 2.0.3.0 for package: banshee-1-1.4.1-12.8.x86_64 Error: Missing Dependency: mono(taglib-sharp) = 2.0.3.0 is needed by package banshee-1-1.4.1-12.8.x86_64 The requirements for banshee-1 are computed during an rpm build with the script: /usr/bin/mono-find-requires The script outputs for requires mono(taglib-sharp) = 2.0.3.0. (During the rpmbuild process) This binds rpm to _this_ _exact_ version, but according to guidline 2.0.3.2 should be compatible. (rpm does not know about this guideline, it simply compares the strings) Normal libs in LINUX For example: under unix you have libfoo-major.midi.mini versions and every change in a mini version is expected to be binary compatible. Everything else is an error. I dont know if taglib 2.0.3.0 is binary compatible to 2.0.3.2 but according to the general practice it should be. But rpm think they are incompatible. Solution? = I dont know if this is a solution and any change to the scripts (mono-find-provide/requieres) should be considered carefully, because it affects everey rpm based distro. But what about this: - mono-find-provides could be left as it is but the - mono-find-requires should return different values. Example: mono-find-provides returns mono(taglib-share) = 2.0.3.0 and mono-find-requires returns mono(taglib-share) = 2.0.3.0 mono(taglib-share) = 2.1.0.0 I don't have tested this but it may work. regards, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Chiron.exe on mono 2.4.2.1 crashes with System.TypeLoadException
Jimmy Schementi wrote: My fault, I can run Chiron from ironruby-0.6 also, though recent builds of it are busted. I'm getting on a plane soon, but when I land I can look at the diff between 0.6 and now (unless someone else wants to on github). Ah, ok. Any comments on my recent post to the moonlight list, or should I also send that here? That issue is most important, as even without Chiron I can't get a DLR app running in Moonlight. I think this is a question for Miguel. Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Chiron.exe on mono 2.4.2.1 crashes with System.TypeLoadException
On Wed, Jul 22, 2009 at 10:24 AM, Thomas Wiest twi...@novell.com wrote: Jimmy Schementi wrote: My fault, I can run Chiron from ironruby-0.6 also, though recent builds of it are busted. I'm getting on a plane soon, but when I land I can look at the diff between 0.6 and now (unless someone else wants to on github). Ah, ok. Looked at the changes and no code changes would have caused this. Might be some configuration thing, but I'm not too worried about it. I'll look into it after OSCon and get back to you. Any comments on my recent post to the moonlight list, or should I also send that here? That issue is most important, as even without Chiron I can't get a DLR app running in Moonlight. I think this is a question for Miguel. Nevermind, I got everything working ... :) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] dependency conflicts on rpm based distros
Hi Martin, If mono-find-requires says that 2.0.3.0 is required that's really what is required and 2.0.3.2 will not work. There are certainly problems with the mono-find-* scripts but that is not one of them. You could verify what I'm saying by manually installing banshee using the --nodeps option passed to rpm. You will find that banshee will not run properly without the correct version of taglib-sharp. Andrew Martin Vogt v...@itwm.fraunhofer.de 07/22/09 9:39 AM Hello, I think the current way of defining dependencies in rpm files for mono is broken. The scripts, which actually do it is part of the mono distribution and affects every rpm based distro. (This is for mono 2.0 but the script is the same for 2.4) I don't find any good resources about library versioning and compatibility only these: http://mono-project.com/Mono:Versioning http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html But in Section 3.2.1: - Each of the libraries in the GAC has an assembly version number that consists of 4 parts (major, minor, build and revision number) It is general practice and recommended by Microsoft that a library is ABI compatible when only the build and revision number change and the major and minor number stay the same. The automatic generated provides/requires during rpmbuild do _not_ follow this general practice an this leads to ugly dependency problems. (On rpm updates) (See the example) Background == Its not easy to describe, but it has to do with the scripts: * mono-find-provides * mono-find-requires which are called during rpmbuild time. I think these scripts work too strict. read on. For example: The interaction on the package banshee-1 and taglib-sharp. In OpenSuSE 11.1 is an update from taglib-sharp from 2.0.3.0 to 2.0.3.2. If I start rpm update I get: Processing Dependency: mono(taglib-sharp) = 2.0.3.0 for package: banshee-1-1.4.1-12.8.x86_64 Error: Missing Dependency: mono(taglib-sharp) = 2.0.3.0 is needed by package banshee-1-1.4.1-12.8.x86_64 The requirements for banshee-1 are computed during an rpm build with the script: /usr/bin/mono-find-requires The script outputs for requires mono(taglib-sharp) = 2.0.3.0. (During the rpmbuild process) This binds rpm to _this_ _exact_ version, but according to guidline 2.0.3.2 should be compatible. (rpm does not know about this guideline, it simply compares the strings) Normal libs in LINUX For example: under unix you have libfoo-.. versions and every change in a mini version is expected to be binary compatible. Everything else is an error. I dont know if taglib 2.0.3.0 is binary compatible to 2.0.3.2 but according to the general practice it should be. But rpm think they are incompatible. Solution? = I dont know if this is a solution and any change to the scripts (mono-find-provide/requieres) should be considered carefully, because it affects everey rpm based distro. But what about this: - mono-find-provides could be left as it is but the - mono-find-requires should return different values. Example: mono-find-provides returns mono(taglib-share) = 2.0.3.0 and mono-find-requires returns mono(taglib-share) = 2.0.3.0 mono(taglib-share) = 2.1.0.0 I don't have tested this but it may work. regards, Martin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
