[Bug 282121] New: broken checks in rpmlint: useless-explicit-provides
https://bugzilla.novell.com/show_bug.cgi?id=282121 Summary: broken checks in rpmlint: useless-explicit-provides Product: openSUSE 10.3 Version: Alpha 4plus Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: dmueller@novell.com ReportedBy: wberrier@novell.com QAContact: qa@suse.de In building mono-core in autobuild, I get these kinds of warnings: W: mono-winforms useless-explicit-provides mono(System.Windows.Forms) W: mono-winforms useless-explicit-provides mono(System.Drawing.Design) W: mono-winforms useless-explicit-provides mono(System.Design) W: mono-winforms useless-explicit-provides mono(Accessibility) But if I see the provides for mono-winforms: brubeck:/usr/src/packages/RPMS/x86_64# rpm -qp --provides mono-winforms-1.2.4-1.x86_64.rpm mono-window-forms mono(Accessibility) = 1.0.5000.0 mono(Accessibility) = 2.0.0.0 mono(System.Design) = 1.0.5000.0 mono(System.Design) = 2.0.0.0 mono(System.Drawing.Design) = 1.0.5000.0 mono(System.Drawing.Design) = 2.0.0.0 mono(System.Windows.Forms) = 1.0.5000.0 mono(System.Windows.Forms) = 2.0.0.0 mono-winforms = 1.2.4-1 They are duplicated, but with different version numbers. Or, am I missing something? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121 ------- Comment #1 from wberrier@novell.com 2007-06-07 16:53 MST ------- There are also some other checks that don't necessarily apply to cil (mono) packages: W: mono-core explicit-lib-dependency libgdiplus You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. Mono can invoke from libraries in ways that are not currently detected by the rpm shlib searching scripts, unless the files are referenced in as assembly's config files (see mono-find-requires). Next one: E: mono-nunit devel-file-in-non-devel-package (Badness: 50) /usr/lib64/pkgconfig/mono-nunit.pc A development file (usually source code) is located in a non-devel package. If you want to include source code in your package, be sure to create a development package. There are some cases where mono relies on .pc files during runtime. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121 dmueller@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |wberrier@novell.com ------- Comment #2 from dmueller@novell.com 2007-06-08 07:57 MST ------- regarding useless-explicit-provides: thats what the check is about. you have new and old versions provided, normally one provides only one version, as requirements should be in the form of ">=", the 2.0.0 one should be enough. regarding libgdiplus. it seems to be, judging from strings, that System.Drawing.dll depends on that library. isn't it possible to extract that dependency there via the mono-find-requires script? when does mono rely on .pc files? and why? that seems to be horribly broken. could you explain to my why it needs that before I try to invent a detection mechanism? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121 ------- Comment #3 from wberrier@novell.com 2007-06-09 01:33 MST ------- useless-explicit-provides: NET assemblies are versioned with a version and strong name. It was MS' way of solving DLL hell. Anyway, .net executables reference a certain version of an assembly at runtime. mono-find-provides/requires resolves those dependencies and requirements. In short, 2.0.0 doesn't satisfy 1.0.0, so both versions are absolutely needed. If you end up making an exception for them, all these types of deps/reqs are keyed with 'mono( )'. libgdiplus: It is possible to extract the 'module references' (the mono debian scripts do it), but this hasn't been implemented in mono-find-requires yet because there are several false positives (which debian ignores, so it's best effort). As of recent, we do have auto deps from an assembly's .config file, which is a good start and works for pretty much all mono apps. Rather than implement 'moduleref' tracking in rpm, it might be better to require libgdiplus through a config file. (Thinking out loud.. I should do that.) But it comes down to the fact that currently the mono-find-requires scripts don't catch this kind of dependency, and if it did, it would only be best effort. pc files: There are a few reasons that mono doesn't utilize -devel packages. Most importantly, it stems from the fact that .NET doesn't have "headers" or ".la" files. The assemblies are used for compile time as well as runtime. (Mono does have mono-devel, which includes development assemblies, tools, and C devel files for embedding the mono runtime in another application). Using the .pc at runtime: Some code is compiled on the fly at runtime (I'm not talking about the intermediate language->machine code compilation). ASP.net does this, for example. This is best described from the mcs manpage: -pkg:package1[,packageN] The compiler will invoke pkg-config --libs on the set of packages specified on the command line to obtain libraries and directories to compile the code. This is typically used with third party components, like this: $ mcs -pkg:gtk-sharp demo.cs That might seem like a non-traditional usage of a .pc file, but pkg-config works perfectly for these needs. For those reasons, it doesn't make sense to have an assembly in a non-devel package, and then have a -devel package that only contains a .pc file, which is sometimes needed at runtime. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121 ------- Comment #4 from dmueller@novell.com 2007-06-09 02:18 MST ------- hmm, can we elegantly avoid the last issue by moving mcs to mono-devel if it is only needed for asp.net ? libgdiplus: so you're adding this to the .config and I don't care about the lint warning? useless-explicit-provides: I'll add a suppression for mono-like packages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121 ------- Comment #5 from wberrier@novell.com 2007-06-13 17:19 MST ------- (In reply to comment #4)
hmm, can we elegantly avoid the last issue by moving mcs to mono-devel if it is only needed for asp.net ?
The .pc file issues happens in most of the .net libraries, not just in mono-core/mono-devel. If this rule was followed, we'd have lots of extra -devel packages only containing a .pc file.
libgdiplus: so you're adding this to the .config and I don't care about the lint warning?
Yes, and I also changed mono-find-requires to depend on the actual libname instead of the package name.
useless-explicit-provides: I'll add a suppression for mono-like packages.
Wonderful! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=282121#c6
Dirk Mueller
participants (1)
-
bugzilla_noreply@novell.com