Lluis Sanchez Gual
lluis at novell.com
Mon Dec 15 11:06:42 EST 2008
El dv 12 de 12 de 2008 a les 08:56 -0700, en/na Andrew Jorgensen va
> There are some significant problems with the mono-find-(provides|
> requires) scripts as they exist now. Some examples will illustrate
> the problem best:
> smuxi requires mono(log4net) which is provided by log4net but it is
> also provided by mojoportal. If you install mojoportal and then smuxi
> you will not get log4net and smuxi will not run. As a stop-gap we
> currently filter the provides to remove things likelog4net from the
> provides list of mojoportal, for instance, but this is hacky and
> difficult to maintain.
> The first logical step is to modify mono-find-provides so that it does
> not emit a provides for anything which is not in the gac. This has
> the following problem:
> monodevelop-boo requires mono(MonoDevelop.Core) but if
> mono-find-provides does not emit provides for things not installed in
> the gac then nothing provides mono(MonoDevelop.Core).
> We could manually say that monodevelop provides mono(MonoDevelop.Core)
> but this would be error-prone and difficult to maintain, particularly
> as API versions may change between releases and the packager has no
> easy way to see that change.
What's special about monodevelop-boo is that it is an add-in, and
add-ins depend on private (non-gac) assemblies of the applications they
I think the best solution is to have a tool which can detect add-ins and
extract information about what they provide/require. Add-ins have an ID
and a version number, and explicit information about which other add-ins
they depend upon (with version numbers too). So it makes sense to use
that information when building package dependencies.
There is already a tool called mautil which can detect and show
information about add-ins. You can run 'mautil info some.dll' and it
will print the header of the add-in and some other information. I can
implement a new option in that command to show the list of
provides/requires in a way that can be easily parsed by
Mono.Addins supports several ways of declaring add-ins and dependencies.
It can be done with an standalone xml manifest, or with an xml manifest
embedded as resource, or using custom attributes. mautil would have to
be used to check every assembly, but also all .addin and .addin.xml
Improving mono-find-provides/requires in this way would be useful not
only for MD, but also for any application based on Mono.Addins.
> Perhaps there's a way to check if a particular requirement is going
> tobe satisfied from the gac or from some other location and not emit
> arequires if it's not satisfied by the gac? Then packagers would have
> to manually add a requires on the package that provides the assembly.
> Also not desirable I think.
> Another option would be to insist that MonoDevelop
> installMonoDevelop.Core to the gac but maybe that's undesirable. Or
> maybe itis? Please let me know if that's a good solution.
> I don't know how best to solve this issue but it needs to be solved.
> As more mono-based packages are added to linux distributions the
> problem will grow. Please share your well-reasoned ideas and / or
> proposed patches.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list