rpm and mono

Jeff Johnson n3npq at mac.com
Sun Jul 15 18:53:17 CEST 2007


On Jul 15, 2007, at 12:39 PM, Jakub Bogusz wrote:

> On Sun, Jul 15, 2007 at 11:24:19AM -0400, Jeff Johnson wrote:
>> On Jul 15, 2007, at 7:45 AM, Jakub Bogusz wrote:
>>> On Sun, Jul 15, 2007 at 10:44:59AM +0200, Łukasz Jernaś wrote:
>>>> Hello.
>>>>
>>>> I just want to drop a note here that current mono-find-requires
>>>> doesn't find
>>>> libraries p-invoked from mono assemblies. They can be partially
>>>> get from
>>>> monodis --moduleref <assembly> but some sort of mechanism for
>>>> pulling the
>>>> complete soname would be needed, because just the name of the lib
>>>> is included
>>>> in the output from the previous command. Any hints?
>>>
>>> We can read ${dllname}.config and determine dll->soname aliases.
>>> But there is a problem with translating sonames to rpm Requires -  
>>> they
>>> are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
>>> systems with 64-bit mono).
>>>
>>
>> If you send me a test case, I'll get you a patch to rpm.
>
> Well, it's not (directly) rpm problem.

It is an rpm problem: find-provides and find-requires for ELF  
dependencies
are being phased out. There is rpm functionality with attaching
dependencies to files, classifying files using libmagic, determining
sonames at install, not build, time, and whether rpmbuild invokes  
external
helpers per-file or per-package  that are intimately tied to how mono  
soname
dependencies are implemented (if at all).

> And mono dependency generators are part of mono, not rpm.
>

Well, I'll remove the mono scripts (added 2 days ago) from rpm  
sources. ;-)

> Actually:
> 1. We can safely generate (arch-dependent) soname dependencies for
> arch-dependent dotnet* packages (those with glue ELF libraries, like
> gtk-sharp, or gnome-sharp, which started this discussion).
> mono-find-requires script can detect mono version basing on monodis
> (or libmono.so) ELF type.
>
> 2. if we decide to generate soname dependencies for some noarch
> dotnet* package, it won't by noarch any longer.
>

If there are soname dependencies, the package is not "noarch", is it?

73 de Jeff


More information about the pld-devel-en mailing list