File: tutorial.t2t

package info (click to toggle)
cupt 2.10.4%2Bnmu1
links: PTS, VCS
area: main
in suites: bookworm, bullseye
size: 3,144 kB
sloc: cpp: 23,642; perl: 1,599; sh: 40; makefile: 19
file content (2379 lines) | stat: -rw-r--r-- 79,168 bytes
parent folder | download | duplicates (3)
Cupt tutorial
Eugene V. Lyubimkin
%%date

%!preproc(man): '%man% ' ''
%!preproc(man): '(``.*?``)' '**\1**'
%!preproc(man): '^``` (.*)$' '**``\1``**'
%!postproc(man): "^(\.TH.*) 1 "  "\1 7 "
%!postproc(man): ' \(#\w+\)' ''
%!options(html): --toc
%!postproc(html): <HEAD> '<HEAD>\n<STYLE>body{margin:2em;}</STYLE>'
%!postproc: '^the_end_of_the_config_area' ''

the_end_of_the_config_area

%man% = NAME =
%man%
%man% cupt_tutorial - tutorial for cupt package manager
%man%

= PREFACE =

== Abstract ==

Cupt is a high-level package manager for Debian and Debian-derived OSes, with
//dpkg(1)// as a back-end.

The aim of this manual is to describe the all features Cupt package manager has
to manage the system, from the most basics to very advanced tuning. Please
submit your proposals/patches when you see some use case is not covered.

This manual was written for the second major version of Cupt (2.x branch).

== Disadvantages and advantages ==

You might not want to use Cupt, because:

- Cupt is "unofficial" package manager. Currently, nothing in Debian ecosystem
uses Cupt. It also means you won't get a support for it on most of Debian
resources (you can however file bugs or join IRC channel, see //cupt(1)/Reporting//).

- Cupt is not very well tested by users yet. Its userbase is relatively small.
However, you are invited to test it and increase the number of users.

- Some features which are present in other high-level package managers are missing.

Among them: multiarch, GUI and TUI interfaces, cdrom:// URI download method, repositories
without a Release file, integration with //cron(8)//. And there are probably
many more.


You might want to use Cupt to have these, to my best knowledge, unique features:

- integration with debdelta (binary package deltas)

- synchronization by source versions

- strict, full-case, configurable problem resolver

- full tree errors for unresolvable dependency problems

- package manager shell

- satisfy subcommand

- changeset-based system modifications for systems with low free disk space

- option name checker (for the 'cupt::*' option family)

- dpkg action sequences with heuristics to make an average number of packages in interim states low


Also, one of Cupt's targets is to have zero non-wishlist bugs. You might want
to try it if you encountered a bug in other package manager(s).

== Infrastructure ==

Out of existing APT infrastructure, Cupt uses (and shares):

- remote repositories and //sources.list(5)//

- ".deb" archives' cache

- configuration (//apt.conf(5)//)

- preferences (//apt_preferences(5)//)

- database of automatically installed packages


The following infrastructure items are Cupt-specific:

- local cache of repository metadata (since version 2.1.0)

- Cupt-specific configuration (//cupt.conf(5)//)

- system snapshots


== Getting started ==

To start working with Cupt just install it using any present package manager
(for example, ``apt-get install cupt`` or ``aptitude install cupt``) and run
``cupt update`` afterwards.

It should be safe to co-use Cupt and any APT-based package managers.

When using commands that modify a system, you have to either execute ``cupt`` with
root privileges or supply ``--simulate`` (or ``-s``) option.

Use ``cupt help`` to get a list of subcommands and their short descriptions.

= BASICS =

== The debian system as Cupt sees it ==

Cupt package manager sees the Debian system as a set of installed packages and
repositories of available packages.

Each binary package has zero, one or more versions, of which zero or one versions
may be installed.

Any installed package may be marked as **automatically installed**, it means that
user didn't ask for this package to be installed, but it is needed to satisfy
some dependency. Packages which are not automatically installed are
**manually installed**.

Available versions (including installed one) of the binary package have unique
version strings. Since Cupt 2.6, Cupt-specific version string suffixes (for example,
``^installed`` or ``^dhs0``) may be applied. More details on this [here #id_suffixes].

== Errors and warnings ==[errors_and_warnings]

Cupt uses three types of output to user: information, warnings and errors.

All warning messages are prepended with ``W:``. They mean non-critical errors,
which may be, depending on the situation, real errors or things to ignore.

All error messages are prepended with ``E:``. Most of errors block the executing
of the program, but not all.

Errors and warnings are written to the standard error.

All other messages are the information for the user. They are written to
standard output.

== Exploring the system ==

=== what packages are installed? ===

``` cupt pkgnames --installed-only

gives you the list, one package name per line. You can also use

``` dpkg -l | grep "^ii"

for more detailed information.

=== getting information about an installed package ===

``dpkg -s`` //package_name//

or

``cupt show --installed-only`` //package_name//

A second command is preferable, for example, when you want to know is this
package automatically installed or not.

=== details of available package versions ===

To show a default package version:

``cupt show`` //package_name//

Example: ``cupt show dpkg``

To show all available package versions:

``cupt show --all-versions`` //package_name//

If you want to see a Debian changelog for a package, use the subcommand ``changelog``.

Example: ``cupt changelog exim4``

If you want to see a Debian copyright file a for a package, use the subcommand ``copyright``.

Example: ``cupt copyright exim4``

Note: Cupt can show changelogs and copyrights either for installed packages, or
for packages available in official repositories in Debian or Ubuntu.

=== searching for a package ===

To search for a package, specify one or more regular expressions as arguments:

``cupt search`` //keyword1// //keyword2// ... //keywordN//

Example: you want to find a Qt-based audio player:

``cupt search audio qt player``: found qmmp.

``cupt search music qt player``: found also amarok.

Another example: you want to find GTK+-related Perl modules:

``` cupt search --names-only "gtk.*perl"

== Updating repository metadata ==[update_metadata]

To update repository medadata, use

``` cupt update

It's recommended to update metadata every time before you install or upgrade
packages.

Note: Cupt downloads quite a many files to update repository metadata. Some
files may be downloaded in 2-3 different ways (like indexes) or are not so
important (like translations for package descriptions). You may see some
warnings, but if you don't see an error message like

``` E: there were errors while downloading release and index data

, the process overall went fine. You can also check program exit code.

== Modifying the system ==[modifying_system]

=== package actions terminology ===[package_actions_terminology]

When some package is changing its state, Cupt calls the action:

: install

when a package which wasn't installed is now going to be installed

: remove

when a package will be removed

: upgrade

when a new (bigger) version of the already installed package is to be installed

: downgrade

when an old (more less) version of the already installed package is to be installed

: purge

when a package and its configuration files will be removed


=== action preview prompt ===[action_preview_prompt]

An example of action preview prompt:

```
$ cupt install kdm akregator exim4

The following packages will be installed:

exim4 exim4-base exim4-config exim4-daemon-light 

The following packages will be upgraded:

kde-window-manager kdebase-workspace-bin kdebase-workspace-data
kdebase-workspace-kgreet-plugins kdm ksysguard ksysguardd libkdecorations4
libkephal4abi1 libkscreensaver5 libksgrd4 libksignalplotter4
libkwineffects1abi1 libkworkspace4 libplasma-geolocation-interface4
libplasmaclock4abi1 libplasmagenericshell4 libprocesscore4abi1 libprocessui4a
libsolidcontrol4abi1 libsolidcontrolifaces4abi1 libtaskmanager4abi1
libweather-ion6 plasma-dataengines-workspace plasma-desktop
plasma-widgets-workspace 

The following packages will be removed:

libgsasl7 libntlm0 msmtp msmtp-mta

Action summary:
  1 manually installed and 3 automatically installed packages will be installed
  1 manually installed and 25 automatically installed packages will be upgraded
  1 manually installed and 3 automatically installed packages will be removed

Need to get 25.7MiB/83.4MiB of archives. After unpacking 3512KiB will be used.
Do you want to continue? [y/N/q/a/?]
```

In the output above you can see: lists of packages to change the state,
the summary of planned changes, the total download amount of packages (83.4MiB),
the download amount considering the cache of already downloaded archives
(25.7MiB), an estimate of difference in disk usage after the actions
(+3512KiB), a user prompt what to do.

The following answers to a user prompt are available:

: y

accept a solution, i.e. proceed with it

: n

decline a solution, i.e. ask to find another solution

: q

don't do anything, quit immediately

: ?

output a short help about available answers

: a

explained [here #specifying_more_package_expression_arguments]


=== installing packages ===[installing_packages]

To install a package:

``cupt install`` //package_name//

Example: ``cupt install exim4``

To install several packages:

``cupt install`` //package_name_1// //package_name_2// ... //package_name_N//

Example: ``cupt install exim4 kvirc kdm``

=== upgrading packages ===

To upgrade one or more installed packages, use the same commands as for [installing packages #installing_packages].

=== removing packages ===

To remove a package:

``cupt remove`` //package_name//

Example:

``` cupt remove gdb

To remove several packages:

``cupt remove`` //package_name_1// //package_name_2// ... //package_name_N//

Example:

``` cupt remove gdb kvirc exim4

=== upgrading the whole system ===

To upgrade as many packages as possible:

``` cupt full-upgrade

In the mode above, Cupt will even consider removing manually installed
packages. If you want to restrict removing manually installed packages, do

``` cupt full-upgrade --no-remove

Or, shorter:

``` cupt safe-upgrade

There is the third upgrade mode, which is to be used for upgrades to the next
major distribution releases:

``` cupt dist-upgrade

This subcommand upgrades Cupt itself and dpkg at first, and then calls new version of itself to upgrade the rest.

=== purging packages ===

To purge a package, i.e. remove a package along with its configuration files
and maybe some dynamically generated or runtime files:

``cupt remove --purge`` //package_name//

Or:

``cupt purge`` //package_name//

To purge several packages:

``cupt purge`` //package_name_1// //package_name_2// ... //package_name_N//

Example:

``` cupt purge gdb

== Package archives cleaning ==

Whenever Cupt needs to install, upgrade or downgrade packages it downloads
binary package archives (``.deb`` files) to an archive cache. These archives
are not removed after the first usage so they can be reused later.

If you do upgrades often, it's a good idea to periodically delete old package
archives to save the disk space. It's done by the subcommand ``autoclean``:

``` cupt autoclean

The command above will delete all package archives which do not belong to
currently available repositories.

If you want to remove all archives from the cache, do

``` cupt clean

Both subcommands above will also remove the partially downloaded archive files
which may stay around after the terminated download operations.

= INTERMEDIATE LEVEL =

== Working with multiple package versions ==

=== changing repositories ===

Cupt uses the same repository list format as APT. See //sources.list(5)//.

=== release information ===[release_info]

Each version of a certain package has one or more **source**s where it comes from.

Each source consists of download information and a subrepository information,
or **release information**.

The following properties belong to release information:

: basic URI

a common prefix of URIs for all files which come for this (sub)repository (also
referred as **origin** in APT documentation)

Example: ``http://ftp.fi.debian.org/debian``

: archive

a repository archive name, for example ``testing`` or ``stable``

: codename

a release code name, for example ``wheezy`` or ``sid``

: component

a subrepository component name, for example ``main`` or ``non-free``

: vendor

a vendor name, for example: ``Debian``

: label

a vendor-provided label, for example: ``Debian-Security``

: version

a release version, for example: ``6.0``

: description

a repository description line


Any of properties above may be empty.

To see available releases:

``` cupt policy

Example:

```
 $ cupt policy
 Package files:
   /var/lib/dpkg/status installed/: o=dpkg,a=installed,l=,c=,v=,n=now
   http://ftp.fi.debian.org/debian stable/main: o=Debian,a=stable,l=Debian,c=main,v=6.0,n=squeeze
   http://security.debian.org stable/main: o=Debian,a=stable,l=Debian-Security,c=main,v=6.0,n=squeeze
   http://ftp.fi.debian.org/debian squeeze-updates/main: o=Debian,a=squeeze-updates,l=Debian,c=main,v=,n=squeeze-updates
   http://ftp.fi.debian.org/debian testing/main: o=Debian,a=testing,l=Debian,c=main,v=,n=wheezy
   http://ftp.fi.debian.org/debian testing/contrib: o=Debian,a=testing,l=Debian,c=contrib,v=,n=wheezy
   http://ftp.fi.debian.org/debian testing/non-free: o=Debian,a=testing,l=Debian,c=non-free,v=,n=wheezy
   http://ftp.fi.debian.org/debian unstable/main: o=Debian,a=unstable,l=Debian,c=main,v=,n=sid
   http://ftp.fi.debian.org/debian unstable/contrib: o=Debian,a=unstable,l=Debian,c=contrib,v=,n=sid
   http://ftp.fi.debian.org/debian unstable/non-free: o=Debian,a=unstable,l=Debian,c=non-free,v=,n=sid
   http://ftp.fi.debian.org/debian experimental/main: o=Debian,a=experimental,l=Debian,c=main,v=,n=experimental
```

The format of lines above:

//basic_URI// //archive//``/``//component//``: o=``//vendor//``,a=``//archive//``,l=``//label//``,c=``//component//``,v=``//version//``,n=``//codename//

Note that "installed" release have the archive ``installed`` and the codename ``now``.

To see the release descriptions of releases a version belongs to:

``cupt show --with-release-info`` //package_name//

Example:

``` cupt show --with-release-info dpkg

=== version pinning system ===[pinning]

Each package version has a **pin**, an integer number.

Amongst all versions of the same binary package, the one who has maximal pin is
**policy**, or **preferred** version.  It's also **candidate** in APT
terminology and in Cupt before 2.3.

Cupt assigns pins to package versions according to the APT documentation
(//apt_preferences(5)//). Plus, it adds:

- 1 to pin of every version which has a signed source

- downgrade penalty (the option ``cupt::cache::pin::addendums::downgrade``)

- hold penalty for packages that are 'on hold' (the option ``cupt::cache::pin::addendums::hold``)

- **not automatic** penalty for versions which come solely from sources marked as not automatic, for example, from Debian
``experimental`` distribution (the option ``cupt::cache::pin::addendums::not-automatic``)


Note that sometimes the way APT assigns pins to versions is not the way
described in its documentation, so Cupt's pins (modulo Cupt-specific additions
described above) are not necessarily identical to what APT produces.

=== what package versions are available? ===[binary_package_policy]

``cupt policy`` //package_name//

Example:

```
 $ cupt policy dpkg
 dpkg:
   Installed: 1.15.5.6
   Preferred: 1.15.8.10
   Version table:
      1.15.8.10 991
         http://ftp.fi.debian.org/debian testing/main (signed)
         http://ftp.fi.debian.org/debian unstable/main (unsigned)
         http://ftp.se.debian.org/debian testing/main (signed)
         http://ftp.se.debian.org/debian unstable/main (signed)
  *** 1.15.5.6 100
         /var/lib/dpkg/status installed/ (unsigned)
      1.14.31 -1499
         http://security.debian.org oldstable/main (signed)
```

In the output above we can see: installed version ('1.15.5.6'), preferred version
('1.15.8.10') and a version table. In total, 3 versions of dpkg are available.

For each version in version table we can see (on example of '1.15.8.10'): a version pin ('991'),
a list of repositories where this version is available.

Each repository line is:

//basic_URI// //archive//``/``//component// (//signedness//)

The repository marked as **signed** if it has a valid and
verified cryptographic signature, and **unsigned** otherwise.

=== version string id suffixes ===[id_suffixes]

Starting with version 2.6, Cupt's behavior regarding merging versions having
the same version string changed.

Firstly, Cupt now never merges installed versions with versions from
repositories, since dpkg provides no way to know if the installed version is
the same as the version from repository. All version strings of installed
versions now have ``^installed`` suffix, for example ``1.2.4^installed``.

Secondly, if same versions from different repositories have different hash
sums, instead of discarding everything but first version Cupt now append
suffixes like ``^dhs0`` or ``^dhs315`` to version strings of non-first
versions, for example ``1.2.4^dhs0``.

=== selecting binary package versions ===[selecting_binary_package_versions]

When there are more than one version for a package, Cupt provides following ways to
select a version of the binary package in the arguments of the various subcommands:

: policy version

to select a policy version, just specify a package name alone.

Example:

``` cupt show dpkg

: specific version

to select an exact version of the package, use the suffix ``=``//version//.

Example:

``` cupt show dpkg=1.15.8.10

: by archive or codename

to select a version in release with known [archive or codename #release_info], use the suffix
``/``//archive// or ``/``//codename//.

Examples:

``` cupt show dpkg/unstable

``` cupt show dpkg/sid


The syntax described above is known as **binary package version expression**.
In the //cupt(1)// manual page all subcommands which accept this syntax are clearly
marked as such.

== Combining multiple version arguments ==[multiple_versions_arguments_and_wildcars]

Many subcommands accept several arguments of the same meaning. Examples:

``` cupt show dpkg cupt libpqxx3=3.0.2-1

``` cupt install youtube-dl clive/stable

``` cupt remove libabc-dev libefg-dev libxyz-dev

``` cupt policy perl perl-base

You can use wildcards **''*''** and **?** to select multiple package names. Examples:

- ``cupt show perl-b*``

Shows policy versions of packages which names start with ``perl-b``, for example
``perl-base`` and ``perl-byacc``.

- ``cupt show perl-*/experimental``

Shows experimental version of packages which names start with ``perl-`` and
which have experimental versions. In other words, packages without a version in
``experimental`` distribution won't be selected.

- ``cupt show *=2.0.0-1 | grep Package``

List packages which have a version ``2.0.0-1``. Using wildcards with versions is
maybe useless, but possible.

- ``cupt full-upgrade xserver-xorg-*/installed``

Perform a full upgrade but keep all installed packages with names starting with
``xserver-xorg-`` at their current versions.

- ``cupt show ?aff*``

Show policy versions of packages with names which have 'a', 'f' and 'f' on 2nd,
3rd and 4th positions (starting with 1st), respectively.


== Conditional installation ==[iii]

Starting with Cupt 2.4, there is a special subcommand ``iii`` ("install if
installed") for installing new versions of already installed packages while not
touching uninstalled packages. It behaves like ``install``, but ignores
arguments corresponding to not installed packages.

Examples:

+ You want to upgrade a certain package (say, ``git``) on multiple
machines, where some of these machines have that package installed and some
not. If you have a mechanism to send one command to all machines (say, ssh
multiplexer), you can send the command

``` cupt update && cupt iii git

The second part of the command will do nothing on the machines where ``git`` is
not installed and will install the preferred version of the package ``git``
where this package was installed.

+ You have an X server and some X video drivers installed, and you want to
upgrade all installed drivers. For that you can do

``` cupt iii xserver-xorg-video*



== Overriding package management actions ==

=== Action override options ===

You can use special positional options ``--install``, ``--remove``,
``--purge``, ``--iii``, ``--satisfy``, ``--unsatisfy``, ``--markauto``,
``--unmarkauto``, ``--asauto=yes``, ``--asauto=no``, ``--asauto=default`` to
override the specified action until the end of the arguments or the next action
override option.

Examples:

- ``cupt remove msmtp-mta --install exim4-daemon-light esmtp``

Install packages ``exim4-daemon-light`` and ``esmtp``, remove the package
``msmtp-mta``.

- ``cupt install exim4-daemon-light --remove msmtp-mta esmtp``

Install the package ``exim4-daemon-light``, remove packages ``msmtp-mta`` and ``esmtp``.

- ``cupt purge libkate1 --remove libass4 --purge libdirac-decoder0``

Remove the package ``libass4``, purge packages ``libkate1`` and ``libdirac-decoder0``.

- ``cupt install lightspark --remove gnash --satisfy "iceweasel (>= 5)"``

Install the package ``lightspark``, remove the packae ``gnash``, and make sure that
``iceweasel`` (at least of version ``5``) is installed.

- ``cupt install sieve-connect --unsatisfy "iceweasel (<< 3.5.20)"``

Install the package ``sieve-connect``, upgrade or remove the package ``iceweasel``
if it is installed and has the version lower than ``3.5.20``.

- ``cupt install libv4l-0 cupt --iii libreadline7 vlc*``

Install packages ``libv4l-0`` and ``cupt``, install the preferred version of
``libreadline7`` if it's installed already, install the preferred versions of
packages which names start with ``vlc`` and which are installed already .

- ``cupt remove youtube-dl --install clive --satisfy "iceweasel (>= 4)" --purge cvs subversion --install git --unsatisfy "xinput (<< 1.5)"``

Install packages ``clive`` and ``git``, remove the package
``youtube-dl``, purge packages ``cvs`` and ``subversion``, make sure that the package
``iceweasel`` of version 4 or higher is installed, make sure that the package
``xinput`` either is not installed or has the version ``1.5`` or higher.

- ``cupt install vlc --markauto xine``

Install the package ``vlc`` and mark the package ``xine`` automatically installed.

- ``cupt remove bindfs --unmarkauto fuse``

You have a package ``bindfs`` installed and now don't need it anymore.
``cupt remove bindfs`` shows that the package ``fuse`` will be removed as it was a
dependency of ``bindfs``; you however decide you want to keep it in the system
and run the command above.

- ``cupt install mumble libgeoip1 geoip-dbg``

(in this and following examples we suppose that currently ``mumble`` is
manually installed, ``libgeoip1`` is automatically installed, ``geoip-dbg`` is
not installed)

``geoip-dbg`` will be manually installed.

- ``cupt install --asauto=yes mumble libgeoip1 geoip-dbg``

``mumble`` will be marked as automatically installed, ``geoip-dbg`` will be automatically installed

- ``cupt install --asauto=no mumble libgeoip1 geoip-dbg``

``libgeoip1`` will be marked as manually installed, ``geoip-dbg`` will be manually installed

- ``cupt install --asauto=yes mumble --asauto=default libgeoip1 geoip-dbg``

``mumble`` will be marked as automatically installed, ``geoip-dbg`` will be manually installed

- ``cupt satisfy --asauto=no "iptables (>= 1.4)"``

(assuming ``iptables`` package not installed) if possible, install enough
recent (``1.4`` or later) version of ``iptables``; ``iptables`` itself will be
marked as manually installed, its possible dependencies as automatically
installed


=== Package name suffixes ===

Alternatively, you can supply some suffixes to package names, that suffixes override the current action for the suffixed package(s) only:

: +

"install this"

: -

"remove this"


You can use the **+** modifier in subcommands: ``remove``, ``purge``. Examples:

``cupt remove youtube-dl clive+``: remove ``youtube-dl``, install ``clive``

``cupt purge exim4 msmtp-mta+ mutt/experimental+``: remove ``exim4`` along with
its configuration files, install ``msmtp-mta`` and ``mutt`` (from experimental)

You can use the **-** modifier in the ``install`` and ``*-upgrade``-like subcommands. Examples:

``cupt install gnuchess/unstable gnome-chess pychess-``: install ``gnuchess``
(from ``unstable``), ``gnome-chess``, remove ``pychess``

``cupt full-upgrade cvs-``:

a) ``cvs`` is installed -> do an upgrade with removing ``cvs``

b) ``cvs`` is not installed -> do an upgrade, keeping ``cvs`` uninstalled

== Using package archive deltas ==

Cupt has an integration (through a special download method) with
//debdelta(1)//. To make Cupt try to download archive deltas before downloading
full archives, just install the package ``debdelta`` and that's it. No manual
invocation of debdelta utilities is needed.

See more about debdelta project here: http://debdelta.debian.net/.

== Listing dependency information ==

To list the dependencies of one or more package versions, use the subcommand ``depends``:

``` cupt depends libc6/testing arora/unstable

If you don't want to see Recommends there, use ``--important``:

``` cupt depends --important libc6/testing

If, on the contrary, you want to see even Suggests, use ``--with-suggests``:

``` cupt depends --with-suggests libc6/testing

You can also list selected relations recursively, using ``--recurse``:

``` cupt depends --recurse dpkg

If you want to see a **reverse** dependencies of some version, use the subcommand ``rdepends``:

``` cupt rdepends xz-utils

All the command switches described here are also applicable to ``rdepends`` as well.

== Action preview prompt (extended) ==

=== summary ===

Starting with Cupt 2.3 an action summary is shown by default.

To remove it, use ``--no-summary`` command-line option. To remove it
permanently, set the configuration option
``cupt::console::actions-preview::show-summary`` to ``no``.

Alternatively, you may want to hide details and view only a summary, this can
be achieved by specifying ``--summary-only`` command-line option. This option
can be useful in a conjunction with ``--simulate`` command-line option to have
a quick preview.

=== detailed solution preview ===

You can request more information to show in the [action preview prompt #action_preview_prompt]:

- package versions

Use ``--show-versions`` (``-V``) option. Example:

```
 $ cupt install gcc-4.6 -V
 
 The following packages will be installed:
 
 cpp-4.6 [4.6.0~rc1-1]
 gcc-4.6 [4.6.0~rc1-1]
 gcc-4.6-base [4.6.0~rc1-1]
 libppl-c4 [0.11.2-3]
 libppl9 [0.11.2-3]
 libpwl5 [0.11.2-3]
 libquadmath0 [4.6.0~rc1-1]
 
 The following packages will be upgraded:
 
 binutils [2.20.1-15 -> 2.21.0.20110302-2]
 libcloog-ppl0 [0.15.9-2 -> 0.15.9-3]
 libgcc1 [1:4.5.2-1 -> 1:4.6.0~rc1-1]
 libgomp1 [4.5.2-1 -> 4.6.0~rc1-1]
```

- by-package disk usage changes

Use ``--show-size-changes`` (``-Z``) option. Example:

```
 $ cupt install gcc-4.6 -Z

 The following packages will be installed:
 
 cpp-4.6 <+10.6MiB>
 gcc-4.6 <+15.0MiB>
 gcc-4.6-base <+192KiB>
 libppl-c4 <+4264KiB>  
 libppl9 <+1176KiB>    
 libpwl5 <+100KiB>     
 libquadmath0 <+496KiB>
 
 The following packages will be upgraded:
 
 binutils <+1300KiB>
 libcloog-ppl0
 libgcc1 <+8192B>
 libgomp1 <+16.0KiB>
```

- release archives

Use ``--show-archives`` (``-A``) option. Example:

```
 $ cupt install gcc-4.7 -A
 
 The following packages will be installed:
 
 cpp-4.7 [(experimental)]
 gcc-4.7 [(experimental)]
 gcc-4.7-base [(experimental)]
 libitm1 [(experimental)]
 
 The following packages will be upgraded:
 
 libgcc1 [(installed,testing) -> (experimental)]
 libgomp1 [(installed,testing) -> (experimental)]
 libquadmath0 [(installed,testing) -> (experimental)]
```

- release codenames

Use ``--show-codenames`` (``-N``) option. Example:

```
 $ cupt install libstreams0 -N
 
 The following packages will be upgraded:
 
 libstreamanalyzer0 [(now,squeeze) -> (wheezy,sid)]
 libstreams0 [(now,squeeze) -> (wheezy,sid)]
```

- release components

Use ``--show-components`` (``-C``) option. It's mostly useful in conjunction
with ``--show-codenames`` or ``--show-archives``. Example:

```
 $ cupt install libstreams0 -CN
 
 The following packages will be upgraded:
 
 libstreamanalyzer0 [(now,squeeze/main) -> (wheezy/main,sid/main)]
 libstreams0 [(now,squeeze/main) -> (wheezy/main,sid/main)]
```

- release vendors

Use ``--show-vendors`` (``-O``) option. Useful if you have repositories of more
than one vendor and usually in conjunction with ``-V``, ``-A`` or ``-N``. Example:

```
 $ cupt install libstreams0 -VNO
 
 The following packages will be upgraded:
 
 libstreamanalyzer0 [0.7.2-1+b1(dpkg:now,Debian:squeeze) -> 0.7.7-1(Debian:wheezy,Debian:sid)]
 libstreams0 [0.7.2-1+b1(dpkg:now,Debian:squeeze) -> 0.7.7-1(Debian:wheezy,Debian:sid)]
```

- change reasons

To show, why resolver did the change(s), use ``--show-reasons`` (``-D``) option.
Example:

```
 $ cupt install gcc-4.6 -D
 
 The following packages will be installed:
 
 cpp-4.6
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'cpp-4.6 (= 4.6.0~rc1-1)'
 
 gcc-4.6
   reason: user request
 
 gcc-4.6-base
   reason: cpp-4.6 4.6.0~rc1-1 depends on 'gcc-4.6-base (= 4.6.0~rc1-1)'
 
 libppl-c4
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libppl-c4'
 
 libppl9
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libppl9'
 
 libpwl5
   reason: libppl-c4 0.11.2-3 depends on 'libpwl5'
 
 libquadmath0
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libquadmath0 (>= 4.6.0~rc1-1)'
 
 
 The following packages will be upgraded:
 
 binutils
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'binutils (>= 2.21~)'
 
 libcloog-ppl0
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libcloog-ppl0 (>= 0.15.9-3~)'
 
 libgcc1
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libgcc1 (>= 1:4.6.0~rc1-1)'
 
 libgomp1
   reason: gcc-4.6 4.6.0~rc1-1 depends on 'libgomp1 (>= 4.6.0~rc1-1)'
```

- show not preferred versions

To show packages which will have a not preferred version (which usually means
not (enough) upgraded), use ``--show-not-preferred`` option.

This is enabled for upgrades by default.

For non-upgrade example, the next command may be used to determine the
installed packages which have a better candidate (again, usually that means
they can be upgraded):

```
 $ cupt install --no-auto-remove --show-not-preferred -V
 
 The following packages will have a not preferred version:
 
 comerr-dev [2.1-1.41.12-4], preferred: 2.1-1.41.12-4stable1
 e2fslibs [1.41.12-4], preferred: 1.41.12-4stable1
 e2fsprogs [1.41.12-4], preferred: 1.41.12-4stable1
 libcomerr2 [1.41.12-4], preferred: 1.41.12-4stable1
 libkadm5clnt-mit7 [1.8.3+dfsg-4], preferred: 1.8.3+dfsg-4squeeze2
 libkadm5srv-mit7 [1.8.3+dfsg-4], preferred: 1.8.3+dfsg-4squeeze2
 libkdb5-4 [1.8.3+dfsg-4], preferred: 1.8.3+dfsg-4squeeze2
 libss2 [1.41.12-4], preferred: 1.41.12-4stable1
 linux-image-2.6.32-5-amd64 [2.6.32-34squeeze1], preferred: 2.6.32-38
 openssh-client [1:5.5p1-6], preferred: 1:5.5p1-6+squeeze1
 tzdata [2011g-1], preferred: 2011k-0squeeze1
 
```


You can also combine them.

=== reason chain ===

Instead of displaying the reasons for all changed packages, starting with Cupt 2.6
you can request the reason chain for the specific package. To do this, use the choice **rc**. Example:

```
 $ cupt -s install exim4-daemon-light
 
 The following packages will be installed:
 
 bsd-mailx exim4-base exim4-config exim4-daemon-light liblockfile-bin liblockfile1 
 
 The following packages will be removed:
 
 msmtp-mta 
 
 The following packages are no longer needed and thus will be auto-removed:
 
 libgsasl7 libntlm0 msmtp 
 
 Action summary:
   1 manually installed and 5 automatically installed packages will be installed
   1 manually installed packages will be removed
   3 automatically installed packages are no longer needed and thus will be auto-removed
 
 Need to get 2241KiB/2241KiB of archives. After unpacking 3006KiB will be used.
 Do you want to continue? [y/N/q/a/rc/?] rc
 Enter a binary package name to show reason chain for (empty to cancel): bsd-mailx
 
 bsd-mailx: exim4-base 4.80-6 recommends 'mailx'
   exim4-base: exim4-daemon-light 4.80-6 depends on 'exim4-base (>= 4.80)'
     exim4-daemon-light: user request
 
 Do you want to continue? [y/N/q/a/rc/?] rc
 Enter a binary package name to show reason chain for (empty to cancel): msmtp-mta
 
 msmtp-mta: exim4-daemon-light 4.80-6 conflicts with 'mail-transport-agent'
   exim4-daemon-light: user request
 
 Do you want to continue? [y/N/q/a/rc/?]
```

=== specifying more package expression arguments ===[specifying_more_package_expression_arguments]

In a solution preview (action preview prompt) you have an ability to specify
more package expressions and a restart a resolving process. To do this, use the
choice **a**. Example:

```
 $ cupt install gnash
 
 The following packages will be installed:
 
 dmsetup dosfstools freepats fuse-utils gconf2-common gnash gnash-common
 gstreamer0.10-ffmpeg gstreamer0.10-fluendo-mp3 gstreamer0.10-plugins-bad
 gstreamer0.10-plugins-base gvfs hdparm libass4 libatasmart4
 libboost-thread1.42.0 libcdaudio1 libcelt0-0 libexempi3 libexif12 libfftw3-3
 libflite1 libfuse2 libgconf2-4 libgdu0 libgme0 libgnome-keyring0 libgsf-1-114
 libgsf-1-common libgtkglext1 libgudev-1.0-0 libidl0 libiptcdata0 libkate1
 liblvm2app2.2 libmimic0 libmms0 libmodplug1 libmusicbrainz4c2a libntfs-3g75
 libntfs10 libofa0 libopenspc0 liborbit2 liborc-0.4-0 libparted0debian1
 libpolkit-backend-1-0 libraptor2-0 librasqal3 librsvg2-2 libsgutils2-2
 libslv2-9 libsoundtouch0 libvisual-0.4-0 libvisual-0.4-plugins libwildmidi1
 libyajl1 libzbar0 mtools ntfs-3g ntfsprogs policykit-1 policykit-1-gnome udisks
 
 The following packages will be upgraded:
 
 libblkid1 libdbus-glib-1-2 libdevmapper1.02.1 libglib2.0-0
 libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libpcre3 libpolkit-agent-1-0
 libpolkit-gobject-1-0 librdf0 libschroedinger-1.0-0 libudev0
 
 The following packages will be removed:
 
 libeggdbus-1-0 librasqal2
 
 Need to get 62.3MiB/62.3MiB of archives. After unpacking 105MiB will be used.
 Do you want to continue? [y/N/q/a/?] a
 Enter a package expression (empty to finish): libgnome-keyring0-
 Enter a package expression (empty to finish):
 
 The following packages will be installed:
 
 freepats gnash gnash-common gstreamer0.10-ffmpeg gstreamer0.10-fluendo-mp3
 gstreamer0.10-plugins-bad gstreamer0.10-plugins-base libass4
 libboost-thread1.42.0 libcdaudio1 libcelt0-0 libexempi3 libexif12 libfftw3-3
 libflite1 libgme0 libgsf-1-114 libgsf-1-common libgtkglext1 libgudev-1.0-0
 libiptcdata0 libkate1 libmimic0 libmms0 libmodplug1 libmusicbrainz4c2a libofa0
 libopenspc0 liborc-0.4-0 libraptor2-0 librasqal3 librsvg2-2 libslv2-9
 libsoundtouch0 libvisual-0.4-0 libvisual-0.4-plugins libwildmidi1 libyajl1
 libzbar0
 
 The following packages will be upgraded:
 
 libglib2.0-0 libgstreamer-plugins-base0.10-0 libgstreamer0.10-0 libpcre3
 librdf0 libschroedinger-1.0-0 libudev0
 
 The following packages will be removed:
 
 librasqal2
 
 Leave the following dependencies unresolved:
 
 gstreamer0.10-plugins-base 0.10.30-1 recommends 'gvfs'
 
 Need to get 56.2MiB/56.2MiB of archives. After unpacking 85.6MiB will be used.
 Do you want to continue? [y/N/q/a/?]
```

The effect above is the same as if you specified

``` cupt install gnash libgnome-keyring0-

in the command line from the start.


Starting from Cupt 2.6 you can specify multiple expressions on the same line.

=== colors ===

Some parts of the actions preview will be colored if you enable colors by
setting the option ``cupt::console::use-colors`` to ``auto`` or ``yes`` (see
//cupt.conf(5)//).

In the colored output different colors specify different actions types.
Manually installed package names and potentially unsafe actions have bold
colors.

Starting from Cupt 2.10, colors are enabled on terminals by default (``auto``
setting).

== Adjusting configuration variables ==

=== intro ===

There are two types of configuration variables - **regular** (or **scalar**) and
**list** ones.  Scalar options have a single scalar value, and list option's
value is a list of strings. Modifying a scalar option means substituting its
previous value completely in favor of new specified one, modifying a list
option means adding one more string to the existing list.

Cupt has many configuration variables, some of them may be specified/overridden
using command-line switches, some needs to be modified explicitly. See the full
variable list and descriptions at //cupt.conf(5)//.

To see the current configuration, use ``config-dump`` subcommand. Examples:

```
 $ cupt config-dump | grep recommends
 apt::install-recommends "yes";
 cupt::resolver::keep-recommends "yes";
 cupt::resolver::tune-score::failed-recommends "600";
```
```
 $ cupt config-dump | grep "methods "
 cupt::downloader::protocols::copy::methods { "file"; };
 cupt::downloader::protocols::debdelta::methods { "debdelta"; };
 cupt::downloader::protocols::file::methods { "file"; };
 cupt::downloader::protocols::ftp::methods { "curl"; };
 cupt::downloader::protocols::ftp::methods { "wget"; };
 cupt::downloader::protocols::http::methods { "curl"; };
 cupt::downloader::protocols::http::methods { "wget"; };
 cupt::downloader::protocols::https::methods { "curl"; };
 cupt::downloader::protocols::https::methods { "wget"; };
```

You can distinguish list options there by figure brackets around the values.

=== configuration sources ===

Cupt reads configuration in the following order:

+ from Cupt preconfiguration file (see //cupt.conf(5)/cupt::directory::configuration::pre//)

+ from APT configuration files (conforming to the APT documentation (//apt.conf(5)//))

+ from Cupt-specific configuration files (see //cupt.conf(5)/cupt::directory::configuration//)

+ from the command line (``--option`` (or ``-o``) switches and dedicated switches corresponding to specific options)


=== setting options using the command line ===

To modify a regular option in the command line, use

``-o`` //option_name//``=``//new_value//

Example:

``` cupt install kmail -o cupt::console::assume-yes=yes

To modify a list option (i.e. add a new string) in the command line, use

``-o`` //option_name//``::=``//added_string//

Example:

``` cupt -s update -o "apt::update::pre-invoke::=ls /var"

You can use ``-o`` multiple times.

== Automatically installed packages ==[automatically_installed_packages]

=== view ===

If you want to know, is a certain package automatically installed or not, do

``cupt show --installed-only`` //package_name//

Example:

``` cupt show --installed-only dpkg

To list manually installed packages:

``` cupt showauto --invert

To list automatically installed packages:

``` cupt showauto

=== change ===

To mark some package(s) as automatically installed, use the ``markauto`` subcommand, for example:

``` cupt markauto libqtcore4 udev

To mark some package(s) as manually installed, use the ``unmarkauto`` subcommand, for example:

``` cupt unmarkauto tar traceroute

=== removal ===[auto-removal]

When doing installs/upgrades/etc. all newly installed packages not requested by
user are marked as automatically installed. For every package management
actions Cupt's resolver can determine if some automatically installed packages
are not needed anymore. Automatically installed packages, which are no more a
part of any valuable dependency chain of manually installed packages, are
deleted by default. The names of this process is **auto-removal**.

If you don't want auto-removal to be performed, use ``--no-auto-remove`` switch
or set the option ``cupt::resolver::auto-remove`` to ``no``.

== Soft dependencies ==

All forward interdependencies between packages can be divided into two groups
-- **hard** and **soft** ones. While hard dependencies must be satisfied in order
to make a system (or proposed solution) valid, soft ones may stay unsatisfied.
Hard dependencies are 'Pre-Depends', 'Depends'. Soft dependencies are
'Recommends', 'Suggests' and 'Enhances'. Cupt completely ignores 'Enhances',
but can act on 'Recommends' or 'Suggests'. All the remainder of this section is
dedicated to the last two.

By default, Cupt ignores 'Suggests', but tries to, with an average priority,
satisfy new dependencies in 'Recommends' and keep already satisfied
'Recommends'.

You can use the following options to change the behavior:

: apt::install-recommends

set this to ``no`` to not satisfy new 'Recommends'. See also the command-line
switch ``--no-install-recommends``.

: cupt::resolver::keep-recommends

set this to ``no`` to make resolver ignore all 'Recommends'

: apt::install-suggests

set this ``yes`` to make resolver try to satisfy new 'Suggests'

: cupt::resolver::keep-suggests

set this to ``yes`` to make resolver try to keep already satisfied 'Suggests'


Note 1: having the option ``apt::install-``//X// set to ``yes`` without
``cupt::resolver::keep-``//X// set to ``yes`` as well is useless, Cupt's native
resolver will warn about it.

Note 2: even when the appropriate ``apt::install-``//X// option is set, Cupt
ignores not changed soft dependencies.  Say, if there is an installed package
``gettext`` of version ``1.2`` which ``Recommends: cvs``, a relation ``cvs`` is not
satisfied in the system, and ``gettext`` is upgraded to a version ``1.3`` which also
have the same ``Recommends: cvs``, Cupt won't try to satisfy this dependency.

== Understanding package installation process ==

After you agree with a proposed solution (by entering a positive answer in an
[action preview prompt #action_preview_prompt]) Cupt starts a package
installation process, which is done in several phases:

+ preparation

In this phase Cupt computes the order in which //dpkg(1)// will called and the
options to pass. This phase may take a while for large changes.

+ downloading

In this phase Cupt downloads needed binary packages (``*.deb``). May be empty
if no packages are needed or all needed packages are already in the cache.

+ pre-hooks

In this phase Cupt calls registered pre-hooks (options ``dpkg::pre-invoke`` and
``dpkg::pre-install-pkgs``) if any. Examples of them are //apt-listchanges(1)//,
//apt-listbugs(1)// and //dpkg-preconfigure(1)//.  These hooks may ask questions
and cancel the whole package installation process.

+ action themselves

In this phase Cupt calls dpkg as many times as needed to perform requested
actions.

+ post-hooks

In this phase Cupt calls registered post-hooks (the option
``dpkg::post-invoke``) if any.


Note: Cupt itself does not ask anything from the user during the package
installation process. All questions usually come from programs which Cupt
calls.

Example:

```
 1: # cupt install cmake
```
This is a command line.

```
 2: Building the package cache...
 3: Initializing package resolver and worker...
 4: Scheduling requested actions...
 5: Resolving possible unmet dependencies...
```
These are (optional) information messages from Cupt.

```
 6:
 7: The following 4 packages will be INSTALLED:
 8:
 9: libarchive1 libcurl3 libssh2-1 libxmlrpc-core-c3
 10:
 11: The following 2 packages will be UPGRADED:
 12:
 13: cmake cmake-data
 14:
 15: Need to get 5637KiB/6007KiB of archives. After unpacking 1963KiB will be freed.
 16: Do you want to continue? [y/N/q/a/?] y
```
This is an action preview prompt.

```
 17: Performing requested actions:
```
This is the 'preparation' phase.

```
 18: Get:1 http://ftp.fi.debian.org/debian wheezy/main,sid/main,wheezy/main,sid/main cmake-data 2.8.4+dfsg.1-2 [1224KiB]
 19: Get:2 http://ftp.fi.debian.org/debian wheezy/main,sid/main,wheezy/main,sid/main cmake 2.8.4+dfsg.1-2 [4102KiB]
 20: Get:3 http://ftp.fi.debian.org/debian wheezy/main,sid/main,wheezy/main,sid/main libarchive1 2.8.4-1 [149KiB]
 21: Get:4 http://ftp.fi.debian.org/debian wheezy/main,sid/main,wheezy/main,sid/main libxmlrpc-core-c3 1.16.33-2 [162KiB]
 22: Fetched 5637KiB in 1s.
```
This is the 'downloading' phase.

```
 23: Reading changelogs... Done
```
This is the 'pre-hooks' phase (namely, apt-listchanges in this case).

```
 24: Selecting previously deselected package libarchive1.
 25: (Reading database ... 94022 files and directories currently installed.)
 26: Unpacking libarchive1 (from .../libarchive1_2.8.4-1_i386.deb) ...
 27: Setting up libarchive1 (2.8.4-1) ...
 28: Processing triggers for man-db ...
 29: Selecting previously deselected package libssh2-1.
 30: (Reading database ... 94034 files and directories currently installed.)
 31: Unpacking libssh2-1 (from .../libssh2-1_1.2.6-1_i386.deb) ...
 32: Setting up libssh2-1 (1.2.6-1) ...
 33: Selecting previously deselected package libcurl3.
 34: (Reading database ... 94041 files and directories currently installed.)
 35: Unpacking libcurl3 (from .../libcurl3_7.21.3-1_i386.deb) ...
 36: Setting up libcurl3 (7.21.3-1) ...
 37: Selecting previously deselected package libxmlrpc-core-c3.
 38: (Reading database ... 94058 files and directories currently installed.)
 39: Unpacking libxmlrpc-core-c3 (from .../libxmlrpc-core-c3_1.16.33-2_i386.deb) ...
 40: Setting up libxmlrpc-core-c3 (1.16.33-2) ...
 41: (Reading database ... 94080 files and directories currently installed.)
 42: Removing cmake ...
 43: Processing triggers for man-db ...
 44: (Reading database ... 94071 files and directories currently installed.)
 45: Preparing to replace cmake-data 2.8.1-2 (using .../cmake-data_2.8.4+dfsg.1-2_all.deb) ...
 46: Unpacking replacement cmake-data ...
 47: Setting up cmake-data (2.8.4+dfsg.1-2) ...
 48: emacsen-common: Handling install of emacsen flavor emacs
 49: Processing triggers for man-db ...
 50: Selecting previously deselected package cmake.
 51: (Reading database ... 94087 files and directories currently installed.)
 52: Unpacking cmake (from .../cmake_2.8.4+dfsg.1-2_i386.deb) ...
 53: Setting up cmake (2.8.4+dfsg.1-2) ...
 54: Processing triggers for man-db ...
```
This is the 'action themselves' phase, dpkg's output and messages from packages' maintainer scripts.


In the case the process fails at phase 'action themselves' (either due to bug
in Cupt, dpkg, or packages), you'll see some error messages from dpkg and then
[error messages from Cupt #errors_and_warnings].

== Source packages ==

=== overview ===

Source packages are the files from which binary packages are built. They have two major differences:

- Source packages cannot be "installed" to the system like binary packages.

- Unlike binary packages, source package consists of 3 or more files, not a single one:

 - tarball(s)

 one or more compressed //tar(1)// archives containing an upstream code

 - diff

 a file containing Debian changes, may be missing in the **native** (Debian-specific) packages

 - dsc

 a text file with some headers


=== exploring ===

To view a source package information:

``cupt showsrc`` //package_name//

Example:

``` cupt showsrc cupt

You can specify more than one package, for example:

``` cupt showsrc sed mawk

To view available source versions, pin info and releases versions come from,
use ``policysrc`` subcommand. Its output is the same as for [policy #binary_package_policy]
subcommand. Example:

``` cupt policysrc sed mawk

To download source package(s), use the ``source`` subcommand, for example:

``` cupt source clive youtube-dl

By default ``source`` subcommand also unpack the package so it's ready for the
exploring and building. To prevent this, use the ``--download-only`` switch.
Also, you can download only one part of source package, use switches
``--tar-only``, ``--diff-only`` and ``--dsc-only`` for that.

=== satisfying build dependencies ===

If you want to build binary packages out of a source one, you will have to
satisfy source package's build dependencies before. Use the subcommand
``build-dep`` to do it, for example:

``` cupt build-dep clive

All new packages, installed by this subcommand, will be marked as
[automatically installed #automatically_installed_packages], and will be a
subject for [auto-removal #auto-removal] at next package management action.

So, the process of building binary packages out of source one may be, taking
``clive`` package as an example:

```
 cupt source clive
 cupt build-dep clive
 cd clive-2.2.13 && debuild && cd ../
 [...]
 cupt install
```

The last line will remove all unneeded anymore packages (given auto-removal is
turned on), including those installed by ``build-dep``.

=== selecting source package versions ===[selecting_source_package_versions]

You can select source package versions in two ways:

+ Provide a **source package version expression**. It has the same syntax as
[binary package version expression #selecting_binary_package_versions], but
instead of specifying a binary package name you specify a source package name.

Example:

``` cupt showsrc game-music-emu=0.5.5-2 gcc-defaults/experimental

+ Provide a binary package version expression, which will be converted to a
source package version expression when possible.

Example:

```
 $ cupt show g++/experimental | head -n5
 Package: g++
 Version: 4:4.6.0-2exp1
 Status: not installed
 Source: gcc-defaults
 Source version: 1.101exp1
 $ cupt showsrc g++/experimental | head -n3
 Package: gcc-defaults
 Binary: cpp, g++, g++-multilib, gobjc, gobjc-multilib, gobjc++,
 gobjc++-multilib, gfortran, gfortran-multilib, gccgo, gccgo-multilib,
 libgcj-common, gcj, gij, libgcj-bc, gcj-jdk, gcj-jre-headless, gcj-jre, gcc,
 gcc-multilib, gdc, gcc-spu, g++-spu, gfortran-spu
 Version: 1.101exp1
```

Here, ``g++`` is a binary package name and ``gcc-defaults`` is a source package
name. In the second command, as there is no source package ``g++``, a binary
package was looked up, a version ``4:4.6.0-2exp1`` of it was found, and then a
source version was selected as if you specified

``` cupt showsrc gcc-defaults=1.101exp1

in the first place.


You can supply both syntaxes to all subcommands which work with source
package versions, examples:

``` cupt build-dep clive/unstable

``` cupt source man-db=2.5.9-4

== Package manager shell ==

Cupt has a shell-like environment, in which you can supply any subcommand as if
you typed it in to the command line, but without preceding cupt command name.

Example:

```
 $ cupt shell
 This is interactive shell of cupt package manager.
 cupt>policy libsoprano4
 libsoprano4:
   Installed: 2.2.2+dfsg.1-1
   Preferred: 2.3.0+dfsg.1-2
   Version table:
      2.3.0+dfsg.1-2 501
        http://debian.org.ua/debian unstable/main (signed)
  *** 2.2.2+dfsg.1-1 100
        /var/lib/dpkg/status installed/ (unsigned)
      2.3.0+dfsg.1-1 2
        http://debian.org.ua/debian experimental/main (signed)
 cupt>depends libsoprano4/experimental
 libsoprano4 2.3.0+dfsg.1-1:
   Depends: libc6 (>= 2.2.5)
   Depends: libclucene0ldbl (>= 0.9.20-1)
   Depends: libgcc1 (>= 1:4.1.1)
   Depends: libqt4-dbus (>= 4:4.5.2)
   Depends: libqt4-network (>= 4:4.5.2)
   Depends: libqt4-xml (>= 4:4.5.2)
   Depends: libqtcore4 (>= 4:4.5.2)
   Depends: libstdc++6 (>= 4.1.1)
   Depends: soprano-daemon (= 2.3.0+dfsg.1-1)
 cupt>rdepends soprano-daemon
 soprano-daemon 2.3.0+dfsg.1-2:
   Reverse-Depends: libsoprano4 2.3.0+dfsg.1-2: soprano-daemon (= 2.3.0+dfsg.1-2)
 cupt>show soprano-daemon
 Package: soprano-daemon
 Version: 2.3.0+dfsg.1-2
 Status: not installed
 Source: soprano
 Priority: optional
 Section: utils
 Size: 153KiB
 Uncompressed size: 536KiB
 Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
 Architecture: amd64
 Depends: libc6 (>= 2.2.5), libgcc1 (>= 1:4.1.1), libqt4-dbus (>= 4:4.5.2), libqt4-network (>= 4:4.5.2),
 libqtcore4 (>= 4:4.5.2), libraptor1 (>= 1.4.18), librdf0 (>= 1.0.9), libsoprano4 (>= 2.3.0), libstdc++6 (>= 4.1.1)
 Conflicts: libsoprano-dev (<< 2.3.0+dfsg.1-1), libsoprano4 (<< 2.3.0+dfsg.1-1)
 Replaces: libsoprano-dev (<< 2.3.0+dfsg.1-1), libsoprano4 (<< 2.3.0+dfsg.1-1)
 URI: http://debian.org.ua/debian/pool/main/s/soprano/soprano-daemon_2.3.0+dfsg.1-2_amd64.deb
 MD5: af29b39a741d9a52de91c8e5562e0609
 SHA1: 1dfebe27b79f10911358949e56f89c64b43265eb
 SHA256: d5b290a60de56f6a7e0af44f5265c6668bb4689204556b9022a5233a808349fc
 Description: daemon for the Soprano RDF framework
  Soprano is a pluggable RDF storage, parsing, and serialization framework based
  on Qt 4. Soprano is targeted at desktop applications that need to store RDF
  data. Its API has been optimized for simplicity and ease of use, while its
  modular structure allows it to use various different RDF storage
  implementations as its backend.
  .
  This package contains the Soprano daemon, D-Bus service, parser
  plugins, and a storage plugin for the Redland RDF Application Framework.
 Homepage: http://soprano.sourceforge.net

 cupt>--simulate install libsoprano4

 The following 1 packages will be INSTALLED:

 soprano-daemon 

 The following 1 packages will be UPGRADED:

 libsoprano4 

 Need to get 700KiB/700KiB of archives. After unpacking 196KiB will be used.
 Do you want to continue? [y/N/q] q

 cupt>exit
```

What this mode may be useful for:

- fast queries

When entering shell mode, the configuration is read and cache is built. Until
some management subcommand is executed, query subcommands don't have to re-read
the configuration and cache on each invocation, and most of them execute
instantly in shell mode.

- common configuration changes

As the ``shell`` subcommand, as all others, recognizes //cupt(1)/Common options//,
you can use that to set some configuration options for all the shell session.

Example:

``` cupt shell --simulate -o apt::install-recommends=no

Installing new recommends will be switched off for all the session inside the
shell, and no real actions will be performed for subcommands that change the
system. Note that you can override them (by supplying ``-o cupt::worker::simulate=no``
and ``-o apt::install-recommends=yes``, respectively, for this example).


== Limiting used repositories ==

As of Cupt version 2.3, you can limit the used package repositories for each
package manager invocation without editing the //sources.list(5)//. The
limiting can be done by [repository archive names or codenames #release_info].

The common syntax is:

//limiting_option//``=``//value//``,``//value//``,``...``,``//value//

Use the option ``--include-archives`` or ``--include-codenames`` to use only
specified repositories. In other words, no matter how many repositories are
present in the //sources.list(5)//, only packages from specified repositories
will be considered.

Examples:

- ``cupt rdepends --include-archives=testing,unstable libffi5``

List reverse-dependencies of ``libffi5`` package in ``testing`` and
``unstable``.

- ``cupt safe-upgrade --include-archives=stable,stable-updates``

Upgrade the system, considering only packages from archives ``stable`` and
``stable-updates``.

- ``cupt install xserver-xorg --include-codenames=wheezy``

Install the package ``xserver-xorg``, if its version in the ``wheezy`` is different
than installed one or there is no such package installed. If any packages need
to be changed in order to process this query (e.g., installing new dependencies
or removing conflicting packages), only versions from ``wheezy`` will be
considered.

- ``cupt search --names-only '.*?-perl' --include-archives=experimental``

Search for Perl module packages in ``experimental``.


Use the option ``--exclude-archives`` or ``--exclude-codenames`` to not use
specified repositories.  If a package version has multiple repositories and at
least one of them is not excluded, the version will be visible.

Examples:

- ``search -n cupt --exclude-archives=stable``

Search for Cupt-related packages, but ignore packages from ``stable``.

- ``cupt full-upgrade --exclude-codenames=sid,experimental``

Upgrade not using packages which come only from ``sid`` or ``experimental``.


Limiting repositories can also be done by modifying the
``cupt::cache::limit-releases::*`` family of configuration variables directly.

Note: unlike the [pinning settings #pinning] which only set version priorities,
limiting repositories is an "absolute" tool. For example, if the version has a
very negative pin, it will be still considered for installation if there is no
better choices, but if all repositories which contain a version are not used,
Cupt will forgot about that version from a very start and forever, without
exceptions.

== Logging ==

As of Cupt version 2.2, most actions that effectively change the state of
the system or Cupt itself (namely, [working with packages #modifying_system],
[updating repository metadata #update_metadata] and
working with [system snapshots #system_snapshots]) are logged by default.

The place (the file path) where to place the logs is determined by the option
``cupt::directory::log``. By default, logs are written to ``/var/log/cupt.log``.

There are 4 levels of logging:

: 0
absolutely no logging at all

: 1
very minimal logging

: 2
the significant information is logged

: 3
very detailed logging


Logging levels are set for each subsystem independently. By default, the
logging level for package changes is set to ``2``, other logging levels are set
to ``1``. To change the logging level for some subsystem, use the option
``cupt::worker::log::levels::``//subsystem//.  See //cupt.conf(5)// for details.

Finally, if you want to disable the logging entirely, set the option
``cupt::worker::log`` to ``no``.

= ADVANCED USAGE =

== Functional selectors ==[fse]

**Functional selectors** is a extended syntax for selecting binary or source
versions by their properties or relations. It's available starting with Cupt 2.6.

It can be used whereever
[binary package version expression #selecting_binary_package_versions] and
[source package version expression #selecting_source_package_versions] can be
used. It addition, it can be used as a parameter to ``search --fse``.

The full syntax and function reference can be found in
//cupt_functionalselectors(7)//.

Examples of functional selector expressions (FSE):

- ``essential()``

All essential versions (those which have ``Essential: yes``).

In the command line it will be

``cupt show 'essential()'``

or

``cupt search --fse 'essential()'``

- ``e()``

The same. ``e`` is a shortcut for ``essential``.

- ``package:name(.*req.*)``

All versions which package name contains the substring ``req``.

- ``Pn(.*req.*)``

Same. ``Pn`` is a shortcut for ``package:name``.

- ``and(Pn(b.*), e())``

All versions which are essential and which package name starts with a letter
``b``.

- ``and(Pn(b.*), e)``

Same. In subexpressions ``()`` can be omitted for functions with no parameters.

- ``Pn(b.*) & e()``

Same. ``x & y & z`` is a special shortcut syntax for ``and(x, y, z)``.

- ``or(e, provides(vim))``

Versions which are essential or provide ``vim`` virtual package.

- ``e() | provides(vim)``

Same. ``x | y | z`` is a special shortcut syntax for ``or(x, y, z)``.

- ``xor(Pn(vim.*), provides(vim))``

Versions, which either have a package name which starts with ``vim`` or provide
``vim`` virtual package, but not both.

- ``not(Pn(vim-nox)) & provides(vim)``

Versions which provide ``vim`` virtual package, excluding the package
``vim-nox``.

- ``installed() & priority(extra)``

Installed versions of priority ``extra``.

- ``maintainer(.*lists.alioth.debian.org.*) & priority(required)``

Versions of priority ``required`` and which maintainer email address is a
mailing list hosted on the Alioth service.

- ``field(Python-Version, .*2\.3.*)``

Versions which have a non-standard field ``Python-Version`` with a substring
``2.3`` somewhere in the value.

- ``Pn(.*python.*) & section(utils)``

Versions from ``utils`` section having ``python`` somewhere in the package
name.

- ``package:installed() & release:component(non-free)``

All versions of installed packages which come from ``non-free`` release
component.

- ``uploaders(.*gmail\.com>)``

All source versions where at least one uploader has a Gmail mail address.

- ``binary-to-source(provides(vim))``

All corresponding source versions of those binary versions which provide ``vim``.

- ``recommends(installed() & e)``

All packages which are recommended by installed essential packages.

- ``and( Ys(Pn(xfce4.*))|Ye(Pn(xfce4.*)), not(Pn(xfce4.*)) )``

All packages which are Suggests (``Ys``) or Enhances (``Ye``) of any package
which name starts with ``xfce4``, excluding ``xfce4...`` packages themselves.

- ``with(_x, Pn(xfce4.*), and( Ys(_x)|Ye(_x), not(_x)) )``

Same.

- ``with(_x, Pn(grep), reverse-depends(_x) | reverse-recommends(_x))``

All versions which depend on or recommend ``grep``.

- ``fmap(Pn(grep), reverse-depends,reverse-recommends)``

Same.

- ``build-depends(Pn(grep))``

Build-dependencies of the all available versions of the source package ``grep``.

- ``recursive(_r, Pn(cupt)&i, and( Yd(_r)|Yr(_r), not(Pn(.*downloadmethod.*))) )``

All direct and indirect depended on and recommended packages (excluding those
which have ``downloadmethod`` in the package name from the recursive chain) of
the installed version of ``cupt`` package.

For complex FSEs like this it, the multiline no-shortcut equivalent might be preferred:

```
#!/bin/sh
cupt search --fse '
	recursive(_r, 
		package:name(cupt) & installed(), 
		and(
			depends(_r) | recommends(_r), 
			not( package:name(.*downloadmethod.*) ) 
		)
	)'
```


== System snapshots ==[system_snapshots]

System snapshots, created by Cupt, consist of binary archives of installed
packages.  The idea is you create snapshots at some time, and when after some
changes you system is messed up, you can go back to the working set of
packages.

Caveats:

- The most usual use case for it is downgrade the packages after a bad upgrade,
  but package downgrades are usually not supported, so it have not a guarantee
to work.

- As of now, snapshots does not store an information about automatically
installed packages.

- If the system doesn't boot or messed up to the level that Cupt or dpkg are
unable to run properly, you cannot revert the system.


It's recommended not to use this feature if you have better alternatives
available (for example, LVM snapshots or filesystem-level snapshots).

To create a snapshot, use

``cupt snapshot save`` //snapshot_name//

Example:

``` cupt snapshot save 20110405

To revert the system to a saved snapshot, use

``cupt snapshot load`` //snapshot_name//

Example:

``` cupt snapshot load 20110405

You can also list the available snapshots (``cupt snapshot list``), rename
(``cupt snapshot rename``), remove (``cupt snapshot remove``).

== Satisfying particular dependency relation expressions ==

There is an ability to change the system not by specifying versions of packages
to install or remove, but by specifying dependencies just as some binary
package have them. The subcommand to perform this is ``satisfy``:

``cupt satisfy`` //dependency_expression_1// ... //dependency_expression_N//

Examples:

``` cupt satisfy "xserver-xorg (>> 1.6)" "xserver-common (<< 1.6.1~)"

``` cupt satisfy "nautilus (>= 2.16.0), libnautilus-extension1 (>= 2.16.0), wget (>= 1.10.0)"

``` cupt satisfy "youtube-dl | clive"

If you want some dependency expression to be unsatisfied instead, add minus
(``-``) to the end of an argument:

``` cupt satisfy mail-reader-

Be careful:

``cupt satisfy vim emacs-``: install vim or anything which provides it, remove emacs and anything which provides it

``cupt satisfy "vim, emacs-"``: remove emacs, vim and anything which provides them

== Request type options ==

By default, when you type ``cupt install abcde``, the preferred version of
``abcde`` package will be installed. By default, on ``cupt install abcde/unstable``
the best of ``abcde`` versions found in ``unstable`` distribution will be
installed. Also, by default, ``cupt remove wget/installed`` or
``cupt remove wget/wheezy`` will remove all versions of ``wget`` package (so none of them may
be installed). This is **traditional** selection behavior.

Starting with Cupt 2.6, it's possible to choose (per request) new **flexible**
selection behavior, though traditional selection behavior is still the default.
Flexible behavior is enabled using ``--select=flexible`` (or, shorter,
``--sf``) command line option. Traditional behavior can be (re)enabled using
``--select=traditional`` (or, shorter, ``--st``) command line option.

Flexible selection behavior is often more intuitive.
``cupt --sf install abcde`` will install any version of ``abcde`` package
(with, as usual, resolver choosing versions with higher [pins #pinning] first).
``cupt --sf install abcde/unstable`` will install any version of ``abcde``
found in ``unstable`` distribution. ``cupt --sf remove wget`` will still remove
the package unconditionally just like traditional behavior, but, say,
``cupt --sf remove wget/installed wget/wheezy`` may either remove ``wget``
package or install some its version not from ``wheezy`` distribution.

The command line options above are positional and can be mixed.
``cupt --select=flexible iii jhc ncdu/experimental --select=traditional --remove automake*/installed``
will [install (if were installed) #iii] any version of ``jhc`` and any version
of ``ncdu`` found in ``experimental`` distribution, but unconditionally remove
installed packages which names start with ``automake``.

== Request importance options ==

By default, when you ask Cupt to perform some package management actions, they
will be performed unconditionally. As in, the command will fail if any of
requested actions cannot be performed. Sometimes more flexibility might be
wanted, especially with [wildcards #multiple_versions_arguments_and_wildcars]
and [FSE #fse].

Starting with Cupt 2.6, it's possibly to specify also non-mandatory, or
optional, requests. For optional requests you also specify their importance,
choosing from a three predefined profiles or supplying precise integer value.
The request importance is controlled by ``--importance=`` command line option.

To specify actions which should be tried hard but you accept that some of them
could not be satisfied at reasonable price (e.g. some of them conflicts with
each other or require extremely "bad" changes to the system), use
``--importance=try`` (or its shortcut ``--try``). For example:

```
 $ cupt -s install --try 'provides(vim)' --no-summary
 
 The following packages will be installed:
 
 [...] vim-athena vim-nox 
 
 The following packages will be upgraded:
 
 [...] vim vim-common vim-gtk vim-gui-common vim-runtime 
 
 [...]
 
 Leave the following dependencies unresolved:
 
 user request: install provides(vim) | for package 'vim-gnome'
```

To specify actions with low importance (as in: "do some of them if possible"),
use ``--importance=wish`` (or its shortcut ``--wish``). For example:

```
 $ cupt -s --wish remove *gnome*

 [...]
 
 The following packages will be removed:
 
 gnome-keyring gstreamer0.10-plugins-good libpam-gnome-keyring
 libsoup-gnome2.4-1 
 
 The following packages are no longer needed and thus will be auto-removed:
 
 gcr gstreamer0.10-gconf gstreamer0.10-x iptables libcap-ng0 libcap2-bin
 libdrm-nouveau1a libdv4 libgck-1-0 libgcr-3-1 libgcr-3-common libiec61883-0
 libnfnetlink0 libpam-cap libxtables10 
 
 Leave the following dependencies unresolved:
 
 gksu 2.0.2-6^installed recommends 'gnome-keyring'
 user request: remove *gnome* | for package 'libgnome-keyring-common'
 user request: remove *gnome* | for package 'libgnome-keyring0'
 libwebkitgtk-3.0-0 2.0.4-5 recommends 'gstreamer1.0-plugins-good'
 libwebkitgtk-1.0-0 2.0.4-5 recommends 'gstreamer1.0-plugins-good'
```

To specify precise numeric importance(s), use ``--importance=``//number//. For example:

```
 $ cupt -s install --importance=10000 xmail --importance=15000 nullmailer --no-auto-remove
 
 The following packages will be installed:
 
 nullmailer 
 
 The following packages will be removed:
 
 msmtp-mta 
 
 Leave the following dependencies unresolved:
 
 user request: install xmail | for package 'xmail'
```
```
 $ cupt -s install --importance=20000 xmail --importance=15000 nullmailer --no-auto-remove
 
 The following packages will be installed:
 
 xmail 
 
 The following packages will be removed:
 
 msmtp-mta 
 
 Leave the following dependencies unresolved:
 
 user request: install nullmailer | for package 'nullmailer'
```

You can also, as usually, mix those options and use ``--importance=must`` (or
its shortcut ``--must``) to restore default behavior, for example:

``` cupt install --try pinentry-* --wish *debootstrap --must --select=flexible icedove *xulrunner*

The penalty values of ``--importance=try`` and ``--importance=wish`` are
controlled by configuration options ``cupt::resolver::score::unsatisfied-try``
and ``cupt::resolver::score::unsatisfied-wish``, respectively.

== Changes in systems with a low disk space ==

If you happen to have a system, where the disk space is very limited, doing a
big upgrades or installations can be a problem. For example, you have 1 GiB of
disk space total, installed packages occupy 600 MiB of them, now you want to do
a massive upgrade, and it's needed to download 500 MiB of archives to do that,
and after the upgrade packages will occupy 700 MiB. Here, the simple approach
of download everything needed and then upgrade everything needed wouldn't work
since there is no 1100 MiB of the disk space available. The answer is to do the
upgrade by smaller parts. Now, although it can be done by selecting groups of
packages to upgrade or install by hand, Cupt can try to do it automatically.

To enable the **changeset-based mode** you will be need specify how many space is
available for downloaded files. It's impossible to compute the amount reliably since
changed packages may use some additional space (for example, kernel upgrades)
or you may write or remove something to the filesystem before/while the
upgrading is progressing. A rough guess of 'amount of free space minus 100 MiB' is
a good start.

After you computed the disk space you can give for package archives, specify it
as a value, in bytes, for ``cupt::worker::archives-space-limit`` option.
Example:

``` cupt full-upgrade -o cupt::worker::archives-space-limit=200000000

Once this option is set, an action scheduler will try to divide all the changes
into smaller consecutive changesets so the following conditions are met:

- Download amounts for package changes in any changeset won't exceed the declared limit.

- After each changeset is done, system is fully working in the sense of packages,
i.e. all dependencies are met and there are no packages in interim states.


If such changesets are found, Cupt will proceed with actions, otherwise an
error with a minimal suitable number will be printed.

For each changeset, package archives will be downloaded before doing actions
and removed before the next changeset begins.

== Synchronization by source versions ==

Sometimes it is a good idea to keep installed binary packages which were built
out of same source package (let's call them **related**) to have the same source version.

Related packages are **synchronized** if they have the same source version, i.e.
binary version may not be the same. For example, the following pairs are usually synchronized:

- ``qprint 1.0-1`` and ``qprint-doc 1.0-1``

- ``qprint 1.0-1+b2`` and ``qprint-doc 1.0-1``


But the following are usually not:

- ``qprint 1.0-1`` and ``qprint-doc 1.0-2``


Cupt's resolver tries to synchronize the versions of related binary packages if
the option ``cupt::resolver::synchronize-by-source-versions`` is set to
non-default value.

Note: this option works properly only if you have source packages available for
all the packages touched by a resolver.

Note: this option doesn't touch installed packages.

Example:

``` cupt safe-upgrade -o cupt::resolver::synchronize-by-source-versions=hard


The ``hard`` value means that all changed packages must be synchronized, e.g.
consider the synchronization an additional hard dependency.  The ``soft`` value
means that all unsynchronized changed packages will have a penalty of
``cupt::resolver::score::failed-synchronization``, e.g. consider the
synchronization as additional soft dependency.

Example:

Suppose we have ``libfoo1`` and ``foo`` binary packages which came from the same
source package. We have ``libfoo1 1.2-1`` and ``foo 1.2-1`` installed.

Situation 1: ``libfoo1`` has new ``1.3-1`` version and foo has new ``1.3-1`` version.

Situation 2: ``libfoo1`` has new ``1.3-1`` version and foo has new ``1.3-2`` version.

We do:

``` cupt install foo

What would be done by resolver if we have:

- no synchronization

Situation 1: install new ``foo``, leave ``libfoo1`` as of installed version

Situation 2: install new ``foo``, leave ``libfoo1`` as of installed version

- soft synchronization

Situation 1: install new ``foo`` and ``libfoo1``

Situation 2: install new ``foo``, leave ``libfoo1`` as of installed version

- hard synchronization

Situation 1: install new ``foo`` and ``libfoo1``

Situation 2: give up with an error tree, (assuming ``foo`` depends on
``libfoo1``, if it does not, then install new ``foo``, remove ``libfoo1``)


== Resolver tuning ==

=== score ===

Cupt's native dependency problem resolver plans system changes, if needed, to
make installed packages set correct after making the changes user demand.

In the most cases, there are several solutions to a problem. To choose
amongst them, resolver assign **scores** to all of them.

Score is an integer (positive or negative) and is a sum of version weight
difference and an action modifier. Version weight, or "normalized version
priority", is a version pin value minus a default pin for a preferred versions.
Action modifiers are action type-specific addendums and are controlled by the
option group ``cupt::resolver::score::``//X// (see the full list of them in
//cupt.conf(5)//).

For native resolver, the negative scores indicate "negative" changes, and
positive scores indicate "positive" changes. When several alternative solutions
for a problem are available, they are considered in the score descending order.
The ultimate goal of score system to assign positive scores to everything user
wants and negative scores to everything user doesn't want. But since "positive"
and "negative" is something that varies from user to user and from action to
action, there is no (and cannot be) a silver bullet.

So, how can you adjust solution scores? From the definition of the score
(above) you may adjust [version pinning #pinning] and/or set
resolver score variables to different values.

Examples:

```
$ echo 'q' | cupt -s -t experimental full-upgrade --summary-only | grep "^  "
W: some solutions were dropped, you may want to increase the value of the 'cupt::resolver::max-solution-count' option
  0 manually installed and 48 automatically installed packages will be installed
  129 manually installed and 474 automatically installed packages will be upgraded
  0 manually installed and 32 automatically installed packages will be removed
  2 manually installed and 17 automatically installed packages will have a not preferred version
$ echo 'q' | cupt -s -t experimental full-upgrade --summary-only -o cupt::resolver::score::unsatisfied-recommends=250 | grep "^  "
W: some solutions were dropped, you may want to increase the value of the 'cupt::resolver::max-solution-count' option
  0 manually installed and 43 automatically installed packages will be installed
  129 manually installed and 473 automatically installed packages will be upgraded
  0 manually installed and 34 automatically installed packages will be removed
  2 manually installed and 14 automatically installed packages will have a not preferred version
  4 dependency problems will stay unresolved
$ echo 'q' | cupt -s -t experimental full-upgrade --summary-only -o cupt::resolver::score::new=-1000 | grep "^  "
W: some solutions were dropped, you may want to increase the value of the 'cupt::resolver::max-solution-count' option
  0 manually installed and 30 automatically installed packages will be installed
  124 manually installed and 429 automatically installed packages will be upgraded
  3 manually installed and 70 automatically installed packages will be removed
  9 manually installed and 14 automatically installed packages will have a not preferred version
  7 dependency problems will stay unresolved
$ echo 'q' | cupt -s -t experimental full-upgrade --summary-only -o cupt::resolver::score::new=-1000 -o cupt::resolver::score::downgrade=0 | grep "^  "
W: some solutions were dropped, you may want to increase the value of the 'cupt::resolver::max-solution-count' option
  0 manually installed and 18 automatically installed packages will be installed
  119 manually installed and 464 automatically installed packages will be upgraded
  1 manually installed and 20 automatically installed packages will be removed
  14 manually installed and 37 automatically installed packages will have a not preferred version
  4 dependency problems will stay unresolved
```

=== maximum solution count ===

When an amount of available solutions is big, you may see the following message while resolver is operating:

``` W: some solutions were dropped, you may want to increase the value of the 'cupt::resolver::max-solution-count' option

Cupt's native resolver may have only limited amount of different solutions in
the memory, and this amount is determined by the value of the
``cupt::resolver::max-solution-count`` option. The default value is enough for
requests of small and medium complexity, but may be not enough for request of
high complexity. So, for systems where there is enough free RAM, consider
increasing the value to values like 4000 or even 16000.

== Getting debug information ==

There are several types of debug information available, the debug output is
turned on by setting some ``debug::``//type// option to ``yes``. All debug output
lines is prepended with ``D:`` and are sent to standard error.

: resolver

The native resolver will output its resolution tree and scores.

The debug option is ``debug::resolver``.

: worker

A debug information regarding scheduling dpkg actions will be printed.

The debug option is ``debug::worker``.

: downloader

A debug information regarding downloader's states will be printed.

The debug option is ``debug::downloader``.

: gpg signatures

The gpg signature checker will output its debug information.

The debug option is ``debug::gpgv``.

: logger

All log messages (of all levels, regardless of logging settings) will be
printed as debug messages.

The debug option is ``debug::logger``.


An example: you want to see a very detailed resolver information regarding your query:

``` cupt install exim4 -o debug::resolver=yes 2>resolver.debug.log

A debug information will be put to a file ``resolver.debug.log``.