[Mono-dev] [mono-packagers] mono-find-(provides|requires)
Andrew Jorgensen
ajorgensen at novell.com
Fri Dec 12 13:06:00 EST 2008
On Fri, 2008-12-12 at 17:33 +0000, Jonathan Pryor wrote:
> *Both* public & private assemblies need to be output (lest we break the
> aforementioned MonoDevelop.Core issue), especially since it's not always
> appropriate to place assemblies into the GAC (e.g. unstable APIs, the
> upstream maintainers don't care to maintain compatibility, etc.).
>
> Thus, I suggest that we modify the output so that public assemblies
> remain as they are -- mono(base-name-of-assembly) -- or modify the
> output so that the assembly version is included. It might be best,
> actually, to just use the fully-qualified assembly name, e.g.
> mono(mscorlib, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=b77a5c561934e089).
It does include version, I failed to mention that. They look like
mono(MonoDevelop.Core) = 1.9.1.0. I agree that it would be better to
use the fully qualified name but it would break compatibility. We'd
need to figure out an upgrade path or something.
> Private assemblies *must* contain the full path, e.g.
> mono(/full/path/to/assembly.dll).
>
> This approach would allow multiple apps to bundle the same assembly
> privately (e.g. log4net) w/o screwing up other apps, and would allow
> apps to strongly specify which public assemblies they depend upon -- two
> different use cases which we've been trying to shoehorn into the same
> solution.
This would work decently if there were a good way to find out the path
of the assembly required by a package that needs it. We would have to
be able to automatically determine that monodevelop-boo requires
mono(/usr/lib/monodevelop/bin/MonoDevelop.Core.dll).
More information about the Mono-devel-list
mailing list