## Filters

Search filtering on the name is done in the backend for efficiency reasons. This can be added into the compiled backend if this is not possible in any new backend design.

Filter options are:

Option | Description
--- | ---
`installed` or `~installed` | If the package is currently installed. Packages returned with the `~installed` filter set are available in remote software sources.
`devel` or `~devel` | Development packages are typically not required for normal operation and typically have the suffixes -devel, -dgb and -static.
`gui` or `~gui` | GUI programs typically depend on gtk, libkde or libxfce.
`application` or `~application` | Packages that provide desktop files and are probably applications.
`free` or `~free` | Free software. The package contains only software and other content that is available under a free license. See the Fedora wiki for a list of licenses that are considered free. If a license cannot be determined from the package metadata, or the status of the license is not known, the package will be marked as 'non-free'.
`visible` or `~visible` | Repositories may want to specify if a package should be visible in an application chooser. This is only really useful for embedded environments where the package list is manually chosen.
`supported` or `~supported` | If the package is supported by the distribution or retailer or is a unsupported third party package.
`basename` or `~basename` | The basename filter will only return results according to the package basename. This is useful if you are searching for pm-utils and you only want to show the main pm-utils package, not any of the `-devel` or `-debuginfo` or `-common` suffixes in the UI. The basename is normally the original name of the source package.
`newest` or `~newest` | The newest filter will only return the newest package available. This is useful if you are searching for `gimp` and only `gimp-2.4.5-1.fc9.i386` would be returned, not `gimp-2.4.5-1.fc9.i386`, `gimp-2.4.4-1.fc9.i386` and `gimp-2.4.3-1.fc9.i386`. NOTE: The `newest` filter processes installed and available package lists separately and so the `installed` or `~installed` filter also has to be specified if only one type of results are required. There is no way to do a `newest` filter across both installed and available packages.
`arch` or `~arch` | The arch filter will only return the packages that match the exact architecture of the system, for instance only showing x86_64 packages on a AMD Turion 64. This would mean that x86_64 packages could be filtered from non-native 32-bit packages. This allows the used to choose non-native packages if a multi-lib policy is allowed.
`source` or `~source` | The source filter will only return source packages. These are typically useful when rebuilding other packages.

So valid options would be:

Option | Description
--- | ---
`none` | All packages installed or available with no filtering
`devel;~installed` | All non-installed development packages
`installed;~devel` | All installed non-development packages
`gui;~installed;~devel` | All non-installed, non-devel gui programs

### Removing installed versions in search results

When outputting a list of packages, it's important to remove the available package if the same version is installed. This is required, as the user may do `SearchName("kernel",filter="none")` and only want to return results that can be operated on. For instance, suppose we have installed:

`kernel-2.6.29.4-167 (installed)`
`kernel-2.6.29.5-191 (installed)`

And in the remote software sources we have:

`kernel-2.6.29.4-167 (fedora)`
`kernel-2.6.29.5-191 (fedora-updates)`
`kernel-2.6.30.1-203 (fedora-updates)`

If we do `Resolve("kernel",filter="none")` we should expect:

`kernel-2.6.29.4-167 (installed)`
`kernel-2.6.29.5-191 (installed)`
`kernel-2.6.30.1-203 (fedora-updates)`

If the `kernel-2.6.29.4-167 (fedora)` result was returned, this will be in the list of results, and is a valid install target. The user will get very confused why `2.6.29.4-167` is both installed and not installed.

### Filter examples

Suppose we have installed:

`kernel-2.6.29.4-167 (installed)`
`kernel-2.6.29.5-191 (installed)`

In the remote software sources we have:

`kernel-2.6.29.4-167 (fedora)`
`kernel-2.6.29.5-191 (fedora-updates)`
`kernel-2.6.30.1-203 (fedora-updates)`

If we do `Resolve("kernel",filter="none")` we should expect:

`kernel-2.6.29.4-167 (installed)`
`kernel-2.6.29.5-191 (installed)`
`kernel-2.6.30.1-203 (fedora-updates)`

If we do `Resolve("kernel",filter="installed")` we should expect:

`kernel-2.6.29.4-167 (installed)`
`kernel-2.6.29.5-191 (installed)`

If we do `Resolve("kernel",filter="~installed")` we should expect:

`kernel-2.6.30.1-203 (fedora-updates)`

If we do `Resolve("kernel",filter="newest;installed")` we should expect:

`kernel-2.6.29.5-191 (installed)`

If we do `Resolve("kernel",filter="newest")` we should expect:

`kernel-2.6.29.5-191 (installed)`
`kernel-2.6.30.1-203 (fedora-updates)`