Provided by: cupt_2.3.2_i386 bug


       cupt_tutorial - tutorial for cupt package manager


       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). Most of it is however applicable to first major  version  (1.x
       branch) too.

   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:  GUI  and  TUI interfaces, cdrom:// URI download
                 method, integration with cron(8). And there are probably many

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

              ·  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

              ·  APT-like option name checker

              ·  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

   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.

       Cupt uses existing APT infrastructure for the work. It should  be  safe
       to co-use Cupt and any APT-based package managers.

       Note:  since  version 2.1.0, Cupt uses its own directory for repository
       index lists, so apt-get update, aptitude update etc. do not change Cupt
       index data anymore.

       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


   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.

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

       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


       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

       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

       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
       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
   package actions terminology
       When some package is changing its state, Cupt calls the action:


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


              when a package will be removed


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


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


              when a package and its configuration files will be removed

   action preview prompt
       An example of action preview prompt:

       $ cupt install kdm akregator exim4
       Building the package cache...
       Initializing package resolver and worker...
       Scheduling requested actions...
       Resolving possible unmet dependencies...

       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

       The following packages will be removed:

       libgsasl7(a) libntlm0(a) msmtp(a) 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.

       For  removed and purged packages, a suffix (a) is appended to a package
       name if a package was automatically installed.

       The following answers to a user prompt are available:


              accept a solution, i.e. proceed with it


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


              don't do anything, quit immediately


              output a short help about available answers


              explained here

   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.

   removing packages
       To remove a package:

       cupt remove package_name


       cupt remove gdb

       To remove several packages:

       cupt remove package_name_1 package_name_2 ... package_name_N


       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,

       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


       cupt purge package_name

       To purge several packages:

       cupt purge package_name_1 package_name_2 ... package_name_N


       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

       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


   Working with multiple package versions
   changing repositories
       Cupt uses the same repository list format as APT. See sources.list(5).

   release information
       Each version of a certain package has one  or  more  sources  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)



              a repository archive name, for example testing or stable


              a release code name, for example wheezy or sid


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


              a vendor name, for example: Debian


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


              a release version, for example: 6.0


              a repository description line

       Any of properties above may be empty.

       To see available releases:

       cupt policy


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

       The format of lines above:

       basic_URI                                            archive/component:

       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


       cupt show --with-release-info dpkg

   version pinning system
       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

              ·  hold  penalty  for  packages  that  are 'on hold' (the option

              ·  not automatic penalty for versions  which  come  solely  from
                 sources  marked  as  not  automatic, for example, from Debian
                 experimental         distribution         (the         option

       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

   what package versions are available?
       cupt policy package_name


        $ cupt policy dpkg
          Version table:
       testing/main (signed)
       unstable/main (unsigned)
       testing/main (signed)
       unstable/main (signed)
         *** 100
                /var/lib/dpkg/status installed/ (unsigned)
             1.14.31 -1499
       oldstable/main (signed)

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

       For  each  version  in  version  table  we  can  see  (on  example   of
       ''):  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.

   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.


              cupt show dpkg

       specific version

              to  select  an  exact  version  of  the  package, use the suffix


              cupt show dpkg=

       by archive or codename

              to select a version in release with known archive  or  codename,
              use the suffix /archive or /codename.


              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
       Many   subcommands  accept  several  arguments  of  the  same  meaning.

       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.

              ·  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.

   Overriding package management actions
   Action override options
       You  can  use  special positional options --install, --remove, --purge,
       --satisfy and --unsatisfy to override the specified  action  until  the
       end of the arguments or the next action override option.


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

       The  command  above  will  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.

   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:

   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

       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)
       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:

              ·  package versions

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

                  $ cupt install gcc-4.6 -V
                  Building the package cache...
                  Initializing package resolver and worker...
                  Scheduling requested actions...
                  Resolving possible unmet dependencies...

                  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 ->]
                  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
                  Building the package cache...
                  Initializing package resolver and worker...
                  Scheduling requested actions...
                  Resolving possible unmet dependencies...

                  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>
                  libgcc1 <+8192B>
                  libgomp1 <+16.0KiB>

              ·  change reasons

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

                  $ cupt install gcc-4.6 -D
                  Building the package cache...
                  Initializing package resolver and worker...
                  Scheduling requested actions...
                  Resolving possible unmet dependencies...

                  The following packages will be installed:

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'cpp-4.6 (= 4.6.0~rc1-1)'

                    reason: user request

                    reason: cpp-4.6 4.6.0~rc1-1 depends on 'gcc-4.6-base (= 4.6.0~rc1-1)'

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'libppl-c4'

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'libppl9'

                    reason: libppl-c4 0.11.2-3 depends on 'libpwl5'

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'libquadmath0 (>= 4.6.0~rc1-1)'

                  The following packages will be upgraded:

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'binutils (>= 2.21~)'

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'libcloog-ppl0 (>= 0.15.9-3~)'

                    reason: gcc-4.6 4.6.0~rc1-1 depends on 'libgcc1 (>= 1:4.6.0~rc1-1)'

                    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
                  Building the package cache...
                  Initializing package resolver and worker...
                  Scheduling requested actions...
                  Resolving possible unmet dependencies...

                  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.

   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
        Building the package cache...
        Initializing package resolver and worker...
        Scheduling requested actions...
        Resolving possible unmet dependencies...

        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(a) librasqal2(a)

        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

        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:


        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.

       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

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

   Adjusting configuration variables
       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

       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

       Cupt reads configuration first from APT configuration files (conforming
       to  the  APT  documentation  (apt.conf(5))),  then  from  Cupt-specific
       configuration  files (see cupt.conf(5)/cupt::directory::configuration),
       then applies those specified in the command line using --option (or -o)
       switch or by dedicated switches corresponding to the option.

       To modify a regular option in the command line, use

       -o option_name=new_value


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

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

       -o option_name::=added_string


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

       You can use -o multiple times.

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

       cupt show --installed-only package_name


       cupt show --installed-only dpkg

       To list manually installed packages:

       cupt showauto --invert

       To list automatically installed packages:

       cupt showauto

       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

       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

       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:


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


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


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


              set this to yes to make resolver try to keep  already  satisfied

       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)  Cupt  starts  a  package installation
       process, which is done in several phases:

              1. 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.

              2. 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.

              3. 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.

              4. action themselves

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

              5. 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.


        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 information messages from Cupt.

        7: The following 4 packages will be INSTALLED:
        9: libarchive1 libcurl3 libssh2-1 libxmlrpc-core-c3
        11: The following 2 packages will be UPGRADED:
        13: cmake cmake-data
        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 wheezy/main,sid/main,wheezy/main,sid/main cmake-data 2.8.4+dfsg.1-2 [1224KiB]
        19: Get:2 wheezy/main,sid/main,wheezy/main,sid/main cmake 2.8.4+dfsg.1-2 [4102KiB]
        20: Get:3 wheezy/main,sid/main,wheezy/main,sid/main libarchive1 2.8.4-1 [149KiB]
        21: Get:4 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.

   Source packages
       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

       To view a source package information:

       cupt showsrc package_name


       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
       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,  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
       You can select source package versions in two ways:

              1. Provide  a source package version expression. It has the same
                 syntax as binary package version expression, but  instead  of
                 specifying a binary package name you specify a source package


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

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


                  $ 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.


        $ cupt shell
        This is interactive shell of cupt package manager.
        Building the package cache... [done]
        cupt>policy libsoprano4
          Installed: 2.2.2+dfsg.1-1
          Preferred: 2.3.0+dfsg.1-2
          Version table:
             2.3.0+dfsg.1-2 501
      unstable/main (signed)
         *** 2.2.2+dfsg.1-1 100
               /var/lib/dpkg/status installed/ (unsigned)
             2.3.0+dfsg.1-1 2
      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 <>
        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)
        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.

        cupt>--simulate install libsoprano4
        Building the package cache... [done]
        Initializing package resolver and worker... [done]
        Scheduling requested actions... [done]
        Resolving possible unmet dependencies...
        The following 1 packages will be INSTALLED:


        The following 1 packages will be UPGRADED:


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


       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.


                 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.

       The common syntax is:


       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.


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

                 List  reverse-dependencies  of libffi5 package in testing and

              ·  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'

                 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.


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

                 Search  for  Cupt-related  packages, but ignore packages from

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

                 Upgrade not using  packages  which  come  only  from  sid  or

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

       Note:  unlike  the  pinning settings 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.

       As of Cupt version 2.2, most actions that effectively change the  state
       of  the  system or Cupt itself (namely, working with packages, updating
       repository metadata and working with system snapshots)  are  logged  by

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

       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

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


   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.


              ·  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

       To create a snapshot, use

       cupt snapshot save snapshot_name


       cupt snapshot save 20110405

       To revert the system to a saved snapshot, use

       cupt snapshot load snapshot_name


       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

       cupt satisfy dependency_expression_1 ... dependency_expression_N


       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

   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

       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.


       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.


       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

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

       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

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

              ·  soft synchronization

                 Situation 1: install new foo and libfoo1

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

              ·  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
       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 pin
       difference (for uninstalled version, zero pin is assumed) and an action
       modifier.  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 and/or set resolver score
       variables to different values.


       $ 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.


              The native resolver will output its resolution tree and scores.

              The debug option is debug::resolver.


              A  debug  information  regarding scheduling dpkg actions will be

              The debug option is debug::worker.


              A  debug  information  regarding  downloader's  states  will  be

              The debug option is debug::downloader.

       gpg signatures

              The gpg signature checker will output its debug information.

              The debug option is debug::gpgv.


              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.