CUPT_TUTORIAL(7)

๐Ÿ“ฆ
version 2.10.4 ยท 4 versions
, in ubuntu noble, ubuntu resolute

โœจ NAME โœจ

cupt_tutorial โ€” tutorial for cupt package manager ๐Ÿ’–

okay so bestie, this is the Cupt tutorial(7) page from the Miscellaneous Information Manual, and it's literally here to get you lowkey obsessed with the cupt package manager. No cap. ๐Ÿซถ


๐ŸŒธ 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). Periodt. โœจ

๐Ÿ’… 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): ๐ŸŒˆ

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 ๐Ÿชž

okay bestie, so here's the whole vibe: Cupt package manager looks at your Debian system and sees it as two things โ€” a set of installed packages and a bunch of repositories of available packages. that's it. that's the whole mental model. ๐Ÿซถ

Every binary package has zero, one or more versions, and out of those, zero or one versions can actually be installed. (yes, a package can just... not exist in any installed form. the audacity.)

Any installed package can be marked as automatically installed. what does that mean? it means you didn't ask for it, bestie โ€” it got pulled in to satisfy some dependency. it's like that one friend who showed up to the party because someone else brought them. Packages that are not automatically installed are manually installed (those are the ones you actually invited โœจ).

Available versions (including the installed one) of a binary package have unique version strings. And since Cupt 2.6, Cupt-specific version string suffixes can get applied โ€” stuff like ^installed or ^dhs0. More details on this here. ๐Ÿ‘‘


๐Ÿšจ Errors and warnings ๐Ÿšจ

Cupt talks to you with three types of output: information, warnings and errors.

  • Warnings โ€” every warning message gets W: prepended to it. These mean non-critical errors, which โ€” depending on the situation โ€” might be real errors, or might just be things to ignore entirely. it's giving "we're fine but watch out".
  • Errors โ€” every error message gets E: prepended to it. Most errors block the executing of the program, but not all. ๐Ÿ’€
  • Errors and warnings get written to standard error.
  • Everything else is just information for you, the user, and it goes to standard output.

๐Ÿ” Exploring the system ๐Ÿ”

๐Ÿ“ฆ what packages are installed?

cupt pkgnames --installed-only

that gives you the list, one package name per line. slay. you can also do

dpkg -l | grep "^ii"

if you want 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 whether this package is automatically installed or not. that's the good stuff ๐Ÿ‘‘

๐Ÿ“œ 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. no in-between, bestie. ๐Ÿ™ˆ

๐Ÿ”ค searching for a package

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

cupt search keyword1 keyword2 ... keywordN

Example: say 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. fr fr. ๐Ÿซก

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:

  • 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

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. look at all that info bestie, she's serving transparency ๐Ÿ’…

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

๐Ÿ“ฅ 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. iconic. โœจ

๐Ÿ—‘๏ธ 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. she upgrades herself, main character energy ๐Ÿ‘‘

๐Ÿงผ 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. (recycling queen ๐Ÿ“)

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

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) 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. (she's flexible like that ๐Ÿ’…)

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 โœจ

okay so every package version has a pin โ€” it's just an integer, a whole number, nothing scary.

and out of all the versions of the same binary package, the one with the biggest pin is the policy version, aka the preferred version. (APT calls this the candidate in its own terminology, and Cupt called it that too before 2.3. iykyk ๐Ÿซถ)

Cupt hands out pins to package versions following the APT documentation (apt_preferences(5)). and then it adds its own lil extras on top:

  • 1 added to the pin of every version that has a signed source ๐Ÿ’…
  • the downgrade penalty โ€” that's the option cupt::cache::pin::addendums::downgrade
  • the hold penalty for packages that are 'on hold' โ€” that's the option cupt::cache::pin::addendums::hold
  • the not-automatic penalty for versions which come solely from sources marked as not automatic, for example from the Debian experimental distribution โ€” that's the option cupt::cache::pin::addendums::not-automatic
real talk bestie: sometimes the way APT actually assigns pins to versions is not the way described in its own documentation ๐Ÿ˜ญ so Cupt's pins (modulo the Cupt-specific additions described above) are not necessarily identical to what APT produces.

๐Ÿฆ‹ what package versions are available?

run this:

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 that output you can peep: the installed version (1.15.5.6), the preferred version (1.15.8.10), and a version table. all in all, 3 versions of dpkg are available.

for every version in the version table you get (using 1.15.8.10 as the example here): its version pin (991) and a list of repositories where that version is available.

every single repository line looks like this:

basic_URI archive/component (signedness)

a repository is marked as signed if it has a valid and verified cryptographic signature, and unsigned otherwise. ๐Ÿ”


version string id suffixes

starting with version 2.6, Cupt's behaviour around merging versions that have the same version string changed. here's the tea:

firstly, Cupt now never merges installed versions with versions from repositories, because dpkg offers literally no way to know whether the installed version is the same as the version from the repository. so all version strings of installed versions now carry the ^installed suffix, for example 1.2.4^installed.

secondly, if the same versions from different repositories have different hash sums, then instead of discarding everything but the first version, Cupt now appends suffixes like ^dhs0 or ^dhs315 to the version strings of the non-first versions, for example 1.2.4^dhs0. โœจ


selecting binary package versions

when there's more than one version of a package, Cupt gives you these ways to pick a version of the binary package in the arguments of the various subcommands:

policy version

to select a policy version, just specify the package name alone. that's it, that's the whole move.

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 a release with a known archive or codename, use the suffix /archive or /codename.

examples:

cupt show dpkg/unstable
cupt show dpkg/sid

all the syntax described above is known as a 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

lots of 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 also use the wildcards * and ? to select multiple package names. examples:

  • cupt show perl-b* โ€” shows policy versions of packages whose names start with perl-b, for example perl-base and perl-byacc.
  • cupt show perl-*/experimental โ€” shows the experimental version of packages whose names start with perl- and which have experimental versions. in other words, packages without a version in the experimental distribution won't be selected.
  • cupt show *=2.0.0-1 | grep Package โ€” lists packages which have a version 2.0.0-1. using wildcards with versions is maybe useless, but it's possible ๐Ÿ’€
  • cupt full-upgrade xserver-xorg-*/installed โ€” performs a full upgrade but keeps all installed packages with names starting with xserver-xorg- at their current versions.
  • cupt show ?aff* โ€” shows policy versions of packages with names which have 'a', 'f' and 'f' on the 2nd, 3rd and 4th positions (starting with the 1st), respectively.

Conditional installation

starting with Cupt 2.4, there's 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 it ignores arguments corresponding to packages that are not installed. ๐ŸŽ€

examples:

  1. say you wanna upgrade a certain package (like git) on multiple machines, where some of those machines have that package installed and some don't. if you have a mechanism to send one command to all machines (like an ssh multiplexer), you can send:
cupt update && cupt iii git

the second part of the command does nothing on the machines where git isn't installed, and installs the preferred version of the package git on the ones where it was installed. periodt.

  1. you have an X server and some X video drivers installed, and you wanna upgrade all the installed drivers. for that, just do:
cupt iii xserver-xorg-video*

Overriding package management actions

Action override options

you can use the 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 until 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 package gnash, and make sure 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's installed and has a 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, and install the preferred versions of packages whose 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 the package iceweasel of version 4 or higher is installed, and make sure the package xinput either is not installed or has 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 the package bindfs installed and now don't need it anymore. cupt remove bindfs shows that the package fuse will be removed since it was a dependency of bindfs; you however decide you wanna keep it in the system, so you run the command above.
  • cupt install mumble libgeoip1 geoip-dbg โ€” (in this and the following examples we suppose that currently mumble is manually installed, libgeoip1 is automatically installed, and 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 is not installed) if possible, install a recent enough (1.4 or later) version of iptables; iptables itself will be marked as manually installed, and its possible dependencies as automatically installed.

Package name suffixes

or, alternatively, you can supply some suffixes to package names โ€” and those suffixes override the current action for the suffixed package(s) only:

  • + โ€” "install this"
  • - โ€” "remove this"

you can use the + modifier in the subcommands remove and 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. like, zero extra steps, it just knows ๐Ÿ’…

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. sneak peek vibes ๐Ÿ‘€

๐ŸŒธ 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

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. mix and match bestie, it's giving custom dashboard ๐Ÿ’…

๐Ÿ’œ 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 ๐Ÿงš

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/?]

And like, that whole vibe? literally the exact same as if you'd typed this at the very start:

cupt install gnash libgnome-keyring0-

Bestie, that - on the end of libgnome-keyring0- is doing SO much work, it's giving "remove this one actually" energy. ๐Ÿ’…

Oh and starting from Cupt 2.6 you can drop multiple expressions on the same line. Slay.


colors ๐ŸŽจ</h2>

Some parts of the actions preview will be colored if you turn colors on by setting the option cupt::console::use-colors to auto or yes (peep cupt.conf(5) for the deets).

In the colored output, different colors mean different action types. Manually installed package names and potentially unsafe actions get bold colors. Very "this one's a little spicy ๐ŸŒถ๏ธ" of them, honestly.

Starting from Cupt 2.10, colors are enabled on terminals by default (that's the auto setting). So yes, it's automatic, no cap. โœจ


Adjusting configuration variables ๐Ÿ› ๏ธ

intro

So there are two types of configuration variables, bestie โ€” regular (a.k.a. scalar) and list ones.

  • Scalar options: one single scalar value, periodt.
  • List options: their value is a list of strings.

Modifying a scalar option = you're replacing the previous value completely with the new one you specified. Modifying a list option = you're just adding one more string to the existing list. That's it, that's the whole difference. ๐Ÿฆ‹

Cupt has a LOT of configuration variables. Some of them you can specify/override with command-line switches, and some of them you just gotta modify explicitly, sorry. Full variable list + descriptions live at cupt.conf(5) โ€” go read it, it's a whole thing.

To see the current configuration, use the config-dump subcommand. Examples, because examples are everything:

$ 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 tell the list options apart there because they've got those fancy figure brackets around the values. { } = list behaviour, iykyk. ๐ŸŽ€

configuration sources

Cupt reads configuration in this order, and it matters, so pay attention bestie:

  1. from Cupt preconfiguration file (see cupt.conf(5)/cupt::directory::configuration::pre)
  2. from APT configuration files (conforming to the APT documentation (apt.conf(5)))
  3. from Cupt-specific configuration files (see cupt.conf(5)/cupt::directory::configuration)
  4. 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. Stack 'em. ๐Ÿ‘‘


Automatically installed packages ๐Ÿ“ฆ

view

Wanna know if a package is 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, like:

cupt markauto libqtcore4 udev

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

cupt unmarkauto tar traceroute

removal

When you do installs/upgrades/etc., all newly installed packages that the user didn't ask for get marked as automatically installed. For every package management action, Cupt's resolver can figure out whether some automatically installed packages aren't needed anymore. Automatically installed packages that are no longer part of any valuable dependency chain of manually installed packages get deleted by default. The name of this process is auto-removal. ๐Ÿ’€

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


Soft dependencies ๐ŸŒธ

All forward interdependencies between packages split into two groups, bestie โ€” hard and soft ones.

  • Hard dependencies must be satisfied to make a system (or a proposed solution) valid.
  • Soft ones may stay unsatisfied. No biggie.

Hard dependencies are Pre-Depends, Depends. Soft dependencies are Recommends, Suggests and Enhances. Cupt completely ignores Enhances, but it can act on Recommends or Suggests. Everything left in this section is about those last two. โœจ

By default, Cupt ignores Suggests, but it tries to satisfy new dependencies in Recommends with an average priority, and it keeps already-satisfied Recommends too. Balanced queen behaviour.

You can use these options to change the behavior:

  • apt::install-recommends โ€” set this to no to not satisfy new Recommends. Peep also the command-line switch --no-install-recommends.
  • cupt::resolver::keep-recommends โ€” set this to no to make the resolver ignore all Recommends.
  • apt::install-suggests โ€” set this to yes to make the resolver try to satisfy new Suggests.
  • cupt::resolver::keep-suggests โ€” set this to yes to make the resolver try to keep already satisfied Suggests.
Note 1: having 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. Not me making the rules, I'm just saying. ๐Ÿ™ˆ
Note 2: even when the appropriate apt::install-X option is set, Cupt ignores not changed soft dependencies. Say there's an installed package gettext of version 1.2 which has Recommends: cvs, the relation cvs is not satisfied in the system, and gettext gets upgraded to a version 1.3 which also has the same Recommends: cvs โ€” Cupt won't try to satisfy this dependency. It stayed the same, so Cupt said "not my problem, babe." ๐Ÿ˜ญ

Understanding package installation process ๐Ÿš€

Once you agree with a proposed solution (by entering a positive answer in an action preview prompt) Cupt starts a package installation process, which happens in several phases:

  1. preparation In this phase Cupt computes the order in which dpkg(1) will be called and which options to pass. This phase may take a while for large changes. Grab a snack. ๐Ÿ“
  2. downloading In this phase Cupt downloads the needed binary packages (*.deb). This may be empty if no packages are needed, or if all the 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. Rude, but okay.
  4. action themselves In this phase Cupt calls dpkg as many times as needed to perform the 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 the questions usually come from programs which Cupt calls. So if something's interrogating you mid-install, it's not Cupt, bestie. ๐Ÿ˜Œ

Example, annotated, because this is the good part:

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

So this bit? This is the "action themselves" phase bestie โ€” it's dpkg's own output plus whatever the maintainer scripts of the packages are yelling about. ๐Ÿ“ข

And ngl, if things go sideways at the 'action themselves' phase (could be a bug in Cupt, could be dpkg, could literally just be the packages being messy), you're gonna see some error messages from dpkg first, and then error messages from Cupt. So likeโ€ฆ two rounds of bad news. ๐Ÿ™ˆ


๐ŸŒธ Source packages ๐ŸŒธ

๐Ÿ’œ overview

Source packages are the files that binary packages get built from. And they're lowkey built different in two big ways:

  • Source packages can't be "installed" onto your system the way binary packages can. Not a thing. Nope. ๐Ÿ’…
  • Unlike binary packages, a source package isn't one single file โ€” it's 3 or more files:
    • tarball(s) โ€” one or more compressed tar(1) archives holding the upstream code โœจ
    • diff โ€” a file with the Debian changes in it. Fun fact: this one can be missing in the native (Debian-specific) packages ๐Ÿซถ
    • dsc โ€” a text file with some headers ๐ŸŽ€

๐Ÿฆ‹ exploring

Wanna peek at a source package's info? Say:

cupt showsrc package_name

Example:

cupt showsrc cupt

And yeah, you can flex on it and ask for more than one package, like:

cupt showsrc sed mawk

Wanna see the available source versions, the pin info, and which releases those versions come from? That's the policysrc subcommand, and its output is the same as the policy subcommand's output. Obsessed. Example:

cupt policysrc sed mawk

To actually download source package(s), use the source subcommand:

cupt source clive youtube-dl

Heads up bestie: by default source also unpacks the package so it's ready for exploring and building. Don't want that? Use the --download-only switch. And if you only want one part of the source package, use --tar-only, --diff-only and --dsc-only for that. Mix and match, it's giving options. ๐Ÿ’…

๐ŸŒˆ satisfying build dependencies

So you wanna build binary packages out of a source one? Periodt, but you've gotta satisfy the source package's build dependencies first. That's what the build-dep subcommand is for:

cupt build-dep clive

Every new package this subcommand installs gets marked as automatically installed, which means it becomes eligible for auto-removal (#auto-removal) at the next package management action. ๐Ÿงš

So the whole "build binary packages out of a source one" pipeline, using clive as the example, goes a lil something like:

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

And that last line? It removes all the packages that aren't needed anymore (assuming auto-removal is turned on), including the ones that build-dep pulled in. Clean up, clean up. ๐Ÿงนโœจ

๐Ÿ‘‘ selecting source package versions

You can pick source package versions in two ways:

  1. Give a source package version expression. Same syntax as a binary package version expression, but instead of a binary package name you put a source package name.

Example:

cupt showsrc game-music-emu=0.5.5-2 gcc-defaults/experimental
  1. Give a binary package version expression, which gets converted into a source package version expression whenever that's 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

So here, g++ is a binary package name and gcc-defaults is a source package name. In that second command, since there's no source package called g++, a binary package got looked up instead, version 4:4.6.0-2exp1 of it was found, and then a source version got selected just as if you'd typed

cupt showsrc gcc-defaults=1.101exp1

from the jump. ๐Ÿซถ

You can hand both syntaxes to all subcommands that work with source package versions, like:

cupt build-dep clive/unstable

cupt source man-db=2.5.9-4

๐Ÿš Package manager shell ๐Ÿš

Cupt has a shell-like environment where you can throw any subcommand at it like you typed it straight into the command line โ€” except you don't have to type cupt first. Iconic behavior honestly. ๐Ÿ’–

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

And what is this mode even for, you ask? Glad you did:

  • fast queries ๐Ÿƒโ€โ™€๏ธ

When you enter shell mode, the configuration gets read and the cache gets built. Until you run some management subcommand, query subcommands don't have to re-read the configuration and cache on each invocation โ€” and most of them execute instantly in shell mode. Instant. Slay.

  • common configuration changes ๐ŸŽ€

The shell subcommand โ€” like all the others โ€” recognizes cupt(1)/Common options, so you can use those to set config options for the whole shell session.

Example:

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

Installing new recommends will be switched off for the entire session inside the shell, and no real actions will be performed for subcommands that change the system. And ngl, 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 package repositories that get used for each package manager invocation โ€” no need to go editing your sources.list(5). Periodt. ๐Ÿซถ

The limiting can be done by repository archive names or codenames.

The common syntax is:

limiting_option=value,value,...,value

Use the option --include-archives or --include-codenames when you want only the repos you name. Like โ€” no matter how many repos are chilling in your sources.list(5), only packages from the repos you specified are even gonna be considered. everyone else? not invited to the party. ๐Ÿ’…

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 wheezy is different than the installed one, or there's no such package installed at all. And if any packages need to be changed to process this query (say, 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.

Now flip it: use --exclude-archives or --exclude-codenames to not use the repos you list. ๐Ÿšซ

Heads up on how exclusion actually works: if a package version lives in multiple repositories and at least one of them is not excluded, the version will be visible. So it's an "any surviving source counts" situation, bestie.

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.

You can also limit repositories by editing the cupt::cache::limit-releases::* family of configuration variables directly, if that's your vibe.

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. ๐Ÿ˜ญ no take-backs.

๐ŸŽ€ Logging ๐ŸŽ€

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 default. โœจ

Where do those logs go? The file path is decided 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, and 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.

And finally โ€” if you want to disable the logging entirely, set the option cupt::worker::log to no.


๐Ÿš€ ADVANCED USAGE ๐Ÿš€

๐ŸŒˆ Functional selectors ๐ŸŒˆ

Functional selectors are an extended syntax for selecting binary or source versions by their properties or relations. Available starting with Cupt 2.6. โœจ

You can use them whereever binary package version expression and source package version expression 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, 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. like a save point in a video game fr fr ๐ŸŽฎ

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. ๐Ÿ‘‘

okay so Cupt 2.6 rolled in something kinda iconic: you can now pick, <italian>per request</italian>, a brand-new flexible selection behavior. the old-school traditional behavior is still the default tho, don't panic ๐Ÿ’…. turn flexible on with --select=flexible (or the short king --sf), and if you wanna go back to trad life, --select=traditional (aka --st) has your back โœจ.

ngl flexible behavior is usually way more intuitive, it's giving common sense. check it:

  • cupt --sf install abcde will install any version of the abcde package (and yeah, as usual, the resolver picks versions with higher pins first ๐Ÿ‘‘).
  • cupt --sf install abcde/unstable will install any version of abcde found in the unstable distribution.
  • cupt --sf remove wget will still remove the package unconditionally, just like traditional behavior does. but like, cupt --sf remove wget/installed wget/wheezy? that may either remove the wget package or install some version of it that's not from wheezy. spicy ๐ŸŒถ๏ธ.

the command line options above are positional and can be mixed, bestie:

cupt --select=flexible iii jhc ncdu/experimental --select=traditional --remove automake*/installed

that one will install (if they were installed) any version of jhc and any version of ncdu found in the experimental distribution, but unconditionally remove installed packages whose names start with automake ๐ŸŽ€.


๐ŸŒธ Request importance options ๐ŸŒธ

by default, when you ask Cupt to do some package management actions, those actions get performed unconditionally. meaning: the whole command fails if any of the requested actions can't be done. but sometimes you want a little wiggle room, especially when you're out here throwing wildcards and FSE around ๐Ÿ˜ญ.

starting with Cupt 2.6 you can also specify non-mandatory, aka optional, requests ๐Ÿฆ‹. for optional requests you also get to say how much you care, by picking one of three predefined profiles or by dropping in a precise integer value. all of this is controlled by the --importance= command line option ๐Ÿ’–.

want actions that should be tried hard but where you accept that some of them might not get satisfied at a reasonable price (like, some of them conflict with each other, or they'd require extremely "bad" changes to the system)? that's --importance=try (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'

for actions with low importance (as in, "just do some of them if possible, no pressure bestie"), use --importance=wish (shortcut: --wish). like so:

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

and for specifying precise numeric importance value(s), it's --importance=number ๐Ÿซถ. example time:

$ 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 per usual, mix those options all together, and use --importance=must (shortcut: --must) to restore the default behavior ๐Ÿ’€:

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

the penalty values of --importance=try and --importance=wish are controlled by the config options cupt::resolver::score::unsatisfied-try and cupt::resolver::score::unsatisfied-wish, respectively ๐ŸŽ€.


๐Ÿ’พ Changes in systems with a low disk space ๐Ÿ’พ

so if you happen to have a system where disk space is very limited (rip), doing big upgrades or installations can be a whole problem ๐Ÿ˜ญ. picture this: you have 1 GiB of disk space total, installed packages are eating 600 MiB of it, and now you wanna do a massive upgrade that needs 500 MiB of archives downloaded, after which packages will occupy 700 MiB. bestie. the simple approach of "download everything needed, then upgrade everything needed" would not work here, because there is no 1100 MiB of disk space available ๐Ÿ’€. the answer is to do the upgrade in smaller parts. and yeah you could hand-pick groups of packages to upgrade or install, but Cupt can try to do it automatically, slay โœจ.

to enable the changeset-based mode you're gonna need to specify how much space is available for downloaded files. it's impossible to compute that amount reliably, since changed packages may use some extra space (kernel upgrades, looking at you ๐Ÿ‘€) or you may write to or remove stuff from the filesystem before/while the upgrading is progressing. a rough guess of 'amount of free space minus 100 MiB' is a good start ๐ŸŒธ.

once you've worked out the disk space you can give to package archives, specify it as a value, in bytes, for the cupt::worker::archives-space-limit option. example:

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

once that option is set, an action scheduler will try to divide all the changes into smaller consecutive changesets so that these conditions are met ๐Ÿซถ:

  • Download amounts for package changes in any changeset won't exceed the declared limit.
  • After each changeset is done, the 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 the 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's a genuinely good idea to keep installed binary packages that were built out of the same source package (let's call them related ๐Ÿ’–) on the same source version.

related packages are synchronized if they have the same source version, i.e. the binary version may not be the same. for example, these 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 these following ones usually are not synchronized:

  • 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 a 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 โ€” like, consider the synchronization an additional hard dependency ๐Ÿ˜ค. the soft value means all unsynchronized changed packages will have a penalty of cupt::resolver::score::failed-synchronization โ€” consider the synchronization an additional soft dependency, gentle vibes ๐ŸŒธ.

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 a new 1.3-1 version and foo has a new 1.3-1 version.
  • Situation 2: libfoo1 has a new 1.3-1 version and foo has a new 1.3-2 version.

we do:

cupt install foo

what the resolver would do, given:

  • no synchronization
    • Situation 1: install new foo, leave libfoo1 at the installed version.
    • Situation 2: install new foo, leave libfoo1 at the installed version.
  • soft synchronization
    • Situation 1: install new foo and libfoo1.
    • Situation 2: install new foo, leave libfoo1 at the 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 the installed packages set correct after making the changes the user demands ๐ŸŽ€.

in most cases there are several solutions to a problem ๐Ÿ˜ญ. to choose amongst them, the resolver assigns scores to all of them.

a score is an integer (positive or negative) and is a sum of a 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 version. action modifiers are action type-specific addendums and are controlled by the option group cupt::resolver::score::X (peep the full list of them in cupt.conf(5)) โœจ.

for the native resolver, negative scores indicate "negative" changes, and positive scores indicate "positive" changes ๐ŸŒˆ. when several alternative solutions for a problem are available, they're considered in score descending order. the ultimate goal of the score system is to assign positive scores to everything the user wants and negative scores to everything the 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 (up above ๐Ÿ‘†) you may adjust version 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 ๐ŸŒ€

okay so bestie, when there are a LOT of possible solutions floating around, you might see this little message while the resolver is doing its thing:

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

Cupt's native resolver can only hold a limited amount of different solutions in memory at once, and that limit is set by the value of the cupt::resolver::max-solution-count option. The default value is totally fine for small and medium complexity requests, but for high complexity requests it might not be enough. So like, if your system has enough free RAM to spare, consider bumping that value up to something like 4000 or even 16000. no cap, it really helps ๐Ÿ’…


๐Ÿ› Getting debug information ๐Ÿ›

There are several types of debug info you can get, and the debug output gets turned on by setting some debug::type option to yes. All debug output lines are prepended with D: and get sent to standard error (stderr, bestie). here's the breakdown:

๐Ÿ” 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.


okay so example time! say you wanna see very detailed resolver information about your query:

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

The debug information will be put into a file called resolver.debug.log. iconic behavior honestly โœจ


and that's the whole tutorial bestie!! ๐ŸŽ€ this page came from the Cupt tutorial, version 3535date, written by the one and only Eugene V. Lyubimkin ๐Ÿ‘‘ you're literally a cupt expert now, go slay those package management queries fr fr ๐Ÿ’–๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from