[mono-packagers] [Mono-dev] mono-find-(provides|requires)

[Jonathan Pryor]

On Fri, 2008-12-12 at 16:28 +0000, Jo Shields wrote:
> 1) Why does mojoportal provide mono(log4net)? If it's a private bundled
> lib which is not added to the GAC, then why lie and say it's provided
> when it isn't?

Because the automagic tools were stupid and said that every assembly
found was a public assembly (even when that wasn't the case).

> If something isn't hitting the GAC, don't say you provide it, because
> you simply don't. If you need to depend on a specific non-GAC app, then
> depend on that app - don't muck about with putting things where they
> don't belong, or with badly formed automatic dependency. Just say "I
> require monodevelop, y'all"

The problem with this is that it requires manual intervention to specify
which packages are required.  Ideally this could all be done
automatically without any manual intervention, and assembly-name ->
package will always be manual.

Which is where listing private assemblies -- with their full path --
could be a workable compromise.  No manual intervention is needed, and
private assemblies are marked as "private" (by using their full path
name), thus removing package conflicts.

> 2) Why does mojoportal even bundle that lib? Every bundled lib is a
> security liability. If you didn't have ten copies of every lib across
> ten different packages, you wouldn't have a problem.

Not every lib should be in the GAC.  Being in the GAC is an indication
that your public API is stable, documented, and won't change, which is
NOT the case for most libraries (and has bitten us before when we placed
non-stable libs into the GAC, such as ICSharpCode.SharpZipLib, iirc).

Requiring use of the GAC isn't a solution, so private assemblies need to
be well supported by whatever tooling we use.

 - Jon