Home / Alt manpages / mono-find-provides(1)

  • mono-find-provides(1)
  • User command
  • linux

Use mono-find-provides to inspect Mono RPM dependencies

You will run mono-find-provides as the packaging helper it actually is: it reads a list of package files from standard input, examines selected Mono assemblies with monodis, and prints RPM Provides entries. Allow about ten minutes for a local check. You do not need root for the examples below.

1. Confirm the installed helper

On this machine the command comes from mono-utils, version 6.8.0.105+dfsg-3.6ubuntu2. The installed manual page is deliberately sparse and says to use the help switch, but the program accepts no documented command-line options. It is a Bash script whose input is the file list supplied by the RPM dependency generator.

$ command -v mono-find-provides
/usr/bin/mono-find-provides
$ dpkg-query -W -f='${Package} ${Version}\n' mono-utils
mono-utils 6.8.0.105+dfsg-3.6ubuntu2
$ file /usr/bin/mono-find-provides
/usr/bin/mono-find-provides: Bourne-Again shell script, ASCII text executable

Do not spend time looking for a normal --help interface. In the installed version, --help, -h, help and --version are ignored as positional arguments and produce no output when standard input is empty.

Checkpoint

You have confirmed the executable and package version. If command -v finds a different copy, stop and inspect that copy before relying on the output below.

2. Supply a file list on standard input

The helper reads one path per input line. It drops paths below /usr/doc/ and /usr/share/doc/, then keeps names ending in .exe or .dll. A second filter keeps only paths containing /gac/, /Facades/ or /4.5/. This filtering is why a random DLL elsewhere on disk may produce no line.

Use a small, known list to test the behaviour without changing package state:

$ printf '%s\n' \
    /usr/lib/mono/4.5/mscorlib.dll \
    /usr/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll \
    /usr/lib/mono/4.5/Facades/System.Runtime.dll \
    /usr/share/doc/mono-utils/README \
  | mono-find-provides
mono(mscorlib) = 4.0.0.0
mono(System) = 4.0.0.0
mono(System.Runtime) = 4.1.0.0

The documentation path is ignored, and each remaining assembly is inspected with monodis --assembly. The output is suitable for an RPM dependency generator: the assembly name becomes the capability and its reported version becomes the value.

Checkpoint

Compare the number of output lines with the number of eligible, readable assemblies you supplied. A missing line can mean that a path was filtered, the file is not an assembly, or the inspection command failed.

3. Use the helper in a packaging pipeline

In its intended role, an RPM build system passes its package file list through standard input. You can reproduce that shape with a text file, but keep the list under review because every path can cause an assembly inspection:

$ find /path/to/staged-root -type f -print > /tmp/mono-file-list
$ mono-find-provides < /tmp/mono-file-list
mono(My.Library) = 1.2.3.0

The exact output depends on the staged tree and the installed assemblies, so the example line is illustrative rather than a guaranteed result. The helper does not write files or alter the input list. Remove the temporary list when you have finished checking it:

$ rm /tmp/mono-file-list

Safety warning

Do not redirect output over a package manifest or generated build file unless you have deliberately chosen that replacement. Use a temporary destination first when another tool will consume the result.

4. Inspect a staged root with prefix

The script defaults to prefix=/usr. It builds libdir, bindir, LD_LIBRARY_PATH and MONO_PATH from that prefix, so a packaging build can point it at a staged installation:

$ printf '%s\n' /tmp/package-root/usr/lib/mono/4.5/My.Library.dll \
  | prefix=/tmp/package-root/usr mono-find-provides
mono(My.Library) = 1.2.3.0

That command only works when the staged prefix contains a usable bin/monodis and lib/libmono-2.0.so.1. On this host, using prefix=/tmp/fake produces monodis missing or unusable, exiting... on standard error and status 1. The helper does not silently fabricate a Provides line when its runtime tools are unavailable.

Keep the prefix assignment attached to this invocation. An exported prefix in a wider shell session can affect unrelated packaging commands.

5. Disable automatic Mono Provides when required

Set DISABLE_MONO_RPM_AUTO_DEPS to any non-empty value to make the helper exit immediately with status 0 and no output:

$ printf '%s\n' /usr/lib/mono/4.5/mscorlib.dll \
  | DISABLE_MONO_RPM_AUTO_DEPS=1 mono-find-provides
$ printf 'status: %s\n' "$?"
status: 0

This is a packaging policy switch, not a diagnostic mode. It suppresses the generated capabilities, so use it only when the surrounding RPM configuration intentionally replaces or disables Mono automatic dependencies. Unset it to restore normal behaviour:

$ unset DISABLE_MONO_RPM_AUTO_DEPS

6. Diagnose empty or failed output

Start with the input stream, not with sudo. An empty result is expected for documentation paths, names without the recognised suffix, and assemblies outside the three accepted directory patterns. Check the paths without changing them:

$ printf '%s\n' /path/to/file.dll | grep -Ev '/usr/doc/|/usr/share/doc/'
$ test -r /path/to/file.dll && echo readable
$ test -x /usr/bin/monodis && echo monodis-ready
$ test -f /usr/lib/libmono-2.0.so.1 && echo libmono-ready

If the final two checks fail, install or repair the package that supplies the Mono utilities through your normal system administration process. Elevated privileges are only relevant to that package-management repair, not to running a readable file list through the helper.

Checkpoint

A successful status 0 means the script completed its loop. It does not prove that every input path was eligible or that every assembly produced a capability. Validate the actual lines passed to the next RPM stage.

Done means

  • You confirmed the installed package and version.
  • You supplied one file path per line on standard input.
  • You accounted for the suffix, directory and documentation filters.
  • You checked monodis and libmono-2.0.so.1 before diagnosing a staged-prefix failure.
  • You treated DISABLE_MONO_RPM_AUTO_DEPS as a deliberate packaging policy change.
  • You verified the generated mono(name) = version lines before another tool consumed them.