About this wiki page
This wiki page is intended to be a relatively quick-start / key reference guide to Debian Systems Administration
for experienced Linux SysAdmins that are inexperienced or less experienced with Debian Systems Administration.
It is written, at least in part, by Debian SysAdmins with as much 20 years or more of Debian SysAdmin experience,
so hopefully one will find key useful information/advice/pointers/references here - and potentially avoid many common problems, missteps incorrect presumptions/assumptions, etc.
Note: this wiki page is a work-in-progress. Although much has been relatively flushed out with relevant information, there remains relevant bits missing, etc. to be (much more) completed.
Note also - anchor tags (/titles within page) may still be in a state of flux - so wouldn't recommend linking to them ... yet. However, am expecting the page URL to remain the same (or redirect to same), so expecting that to be persistent and okay to link to.
- About this wiki page
- Debian: Quick Start Guide / Basic "Care and Feeding"
- What is Debian ? / Why choose Debian?
- Support / Security / Lifecycle
- Package Management
- See Also / References
Debian: Quick Start Guide / Basic "Care and Feeding"
So, presuming one is already rather to quite familiar with Linux Systems Administration, but not, or not so familiar with Debian Systems Administration, and let's say one already has Debian system(s) installed that one needs to take care of and maintain.
Here are some most critical bits to get one started with Debian (more complete information can be found further below in other sections):
mostly presuming stable(/"production") release here (more on that further below)
basic periodic maintenance (within a major release version):
to cover getting update information, downloading, and installing at least relevant updates to fix security and critical bugs, one will want to (at least semi-)regularly do either and/or both of:
manually: # apt-get update && apt-get dist-upgrade
automatically: install(/configure) package: unattended-upgrades
Note that unattended-upgrades will by default do scheduled updates to the host - one may wish to review/adjust the scheduling of those changes (e.g. to not impact production hours, or to stagger timings across hosts, etc.)
- in addition to the above (and whether manual and/or automatic), one may still need to restart service(s) and/or reboot to have, or have all, of the updates/fixes take full effect (e.g. newer libraries - is existing process still using older library that was updated, or is one still running older kernel where newer has been installed?)
announcements and security announcements, one should subscribe to at least these lists:
debian-announce - this is a relatively low volume (about 9 emails per year may be considered pretty typical) list of major news and very important change announcements, including new major releases and minor point releases.
debian-security-announce security advisories - most notably so one can be promptly notified of security issues and available security fixes, and also security end-of-life/end-of-support dates. Note also this is a moderately high volume list (a couple hundred to a few hundred or so emails per month, give or take, being fairly typical), but also, after quick review/skim, one can often ignore many of the security announcement emails - as Debian has more than 59,000 ready-to-use software packages, and for any given installation, one wouldn't have many/most (and couldn't have all) of those packages installed - so many security announcements will generally be for package(s) one doesn't have installed.
distribution/release - know the major version release considerations and what one is configured to use
have a look at the file: /etc/apt/sources.list (and also any files under /etc/apt/sources.list.d/) - these will indicate what repositories one's installation is configured to use. Typically (notably for production) these would be configured for a particular (code) name(d) release, e.g. buster. One would do well to be aware of particular release lifecycles and end-of-life/end-of-support dates, e.g. have a look at Debian Releases (includes end-of-life dates, etc.). For production, one would generally not want to use the generic names such as unstable or testing (both of which are effectively "rolling releases"), or be configured to use names: stable, oldstable, or oldoldstable. (And why wouldn't one want to use those? Because when a new major production version is released, the major versions that stable, oldstable, and oldoldstable refer to all change, and if one's system is configured to use those generic names, as soon as routine updates/upgrades are done (manually or automatically), the systems would go through very jarring changes and quite possibly break and/or be quite disruptive).
major version upgrades: watch debian-announce for information and announcements about major version releases (and also minor version releases). The major version releases also come with excellent pointers to relevant documentation for both installs, and also major version upgrades (notably both the installation documentation, and also release notes). See also Debian Releases for a general view of current state. One can also go straight to the Installation Guide for the current stable version release for installation information (or navigate there easily enough from Debian's main web page).
- support - see the more detailed support information in section(s) further below
Don't Break Debian
how to not break Debian - key common mistakes to avoid (beyond typical more generic Linux systems administration):
- /etc/apt/sources.list (and also any files under /etc/apt/sources.list.d/):
- only use official Debian repositories (these will always and only be under the debian.org domain)
Don't make a FrankenDebian, notably don't mix multiple (notably incompatible) Debian repositories. E.g. one should typically be on the (code) name(d) Debian release (typically whatever the current stable is, e.g. buster at the time of this writing), or (while still supported) that corresponding to oldstable (or if using LTS or ELTS, possibly even older (code) name(s)). One should not, e.g. have more than one of any of these (by code name or generic name): the current oldoldstable, the current oldstable, the current stable, the current testing, unstable or sid. Some slight exceptions: one can combine the particularly matched code name release repositories, e.g. updates, -security (for security updates), proposed-updates (notably if one wants to test what is proposed to go into updates before it's released to updates), and with sid/unstable, one can include experimental.
- adding/removing/updating packages - only use Debian's apt-based package management tools, e.g. apt-get:
# apt-get install package_name
# apt-get remove package_name
- if you find yourself using or needing to use various "force" options, you're probably breaking stuff and/or already dealing with a system that's been broken somehow.
tip: for routine maintenance - notably across minor point releases, or if one is running testing or unstable/sid, in addition to:
# apt-get upgrade
one can also use: # apt-get dist-upgrade
to upgrade packages that would otherwise be held back (notably when base version number of package changes - essentially considered a "new version", vs. "merely" patched/updated (typically fixes backported to) existing version (in which case only minor portions of the package version number change).
support information - notably where not to get / what "advice" not to follow. The Internet is a great information resource. Unfortunately it's also a huge source of misinformation and bad advice. (e.g. typically about 20% of the information on The Internet is anywhere from significantly incomplete/misleading, to dead wrong and even downright dangerous). That doesn't mean one can't also use information/support/guidance from various locations on The Internet, however, for Debian information, one would be highly well advised to mostly consider information under the debian.org domain to be most reliable and authoritative, and also consider information under debian.net (also controlled by the Debian project - but less official / more supplemental information). One may do relatively well to, e.g. restrict search engine(s) to debian.org (or that and debian.net) domain(s) - or to use such to verify information/suggestions from other sources (e.g.: site:debian.org or (site:debian.org OR site:debian.net)).
Debian is not: Ubuntu, Linux Mint, Linux Mint Debian Edition, Finnix, Devuan, Raspbian, nor any of the dozens if not hundreds or more, operating systems which are derived from and projects operated separate from Debian, so much of the information/advice that is or may be relevant and appropriate for derivatives of Debian or other Linux distros, etc., is often neither fitting, relevant, appropriate, not correct for Debian. So, do not presume what applies to Debian derivatives or other Linux distros, necessarily applies or fits to Debian. Also as noted above regarding /etc/apt/sources.list, etc., do not mix non-Debian repositories in with Debian. Note also this is not to be confused with Debian Pure Blends which are fully part of and within Debian itself.
- /etc/apt/sources.list (and also any files under /etc/apt/sources.list.d/):
What is Debian ? / Why choose Debian?
Unique* to Debian
and in brief, unique to Debian:
- Debian is about freedom and being free, most notably see:
- Universal Operating System:
broad selection of packages (more than 59,000 ready-to-use software packages)
More GNU/Linux Distributions are Debian or based upon Debian than any other (GNU/Linux Distributions Timeline) - at least of any GNU/Linux Distribution that continues to exist.
- Debian Developers:
Debian has about a thousand Debian Developers (people known in the database who have status "DD, upl.")
Debian has been around since 1993-08-16
- further information:
Debian Pros "vs." Cons
What, you want more bugs to troubleshoot/fix?
more than 59,000 ready-to-use software packages, lots of options, mostly not forced by someone else's choices
Can't have everything installed at same time (e.g. some packages conflict), lots of choices
stable is highly stable
full support "only" about 3+ years
Democratic/Meritocracy by Debian Developers, no (benevolent?) dictator/overlord/CEO to change all
no (benevolent?) dictator/overlord/CEO to change all
more Linux distros are Debian or based upon Debian than any other existing
can't brag about your special snowflake boutique distro
broad package selection & architecture support suitable to wide variety use cases
not highly optimized to certain specific edge cases
company / commercial entity?
not - can't be bought/sold, always free, can't be bought out
can't buy it out
excellent & free
Internet-only, no toll-free number, volunteers, not much hand-holding, no babysitting nor butt kissing
support lifecycle length
about 3+ years, LTS about 5, more with ELTS
exact end dates not highly predictable long in advance, LTS supports less, ELTS even less
most recent software / "rolling" release
stable+backports, testing, unstable
full support limited to stable (and oldstable for while), not Debian's primary focus/recommendation
Absolutely! Social Contract & DFSG
Don't get non-free by default, but can be added
easily know/determine software free/freedom
Absolutely! non-free not enabled by default
non-free not enabled by default
highly predictable release schedule
kind'a - freezes have schedule, releases projected, releases happen when darn good and ready
releases don't come out like clockwork per some highly predictable schedule well in advance
3rd party support
mostly not highly commonly used nor large, generally not free
3rd party / non-Debian software
can be installed/managed (e.g. via alien)
not as purpose-built for or as commonly used for installing lots of 3rd party software
Debian: Evaluating, Choosing, and Choices
Debian is not only very much about freedom and free (Social Contract & DFSG, etc.), but there are numerous choices one can make within Debian, e.g.:
- non-free? - is non-free firmware needed/desired, or other non-free?
- more than 59,000 ready-to-use software packages - which to install?
One may do some various installations to try out and evaluate Debian - see also Installation guide/manual
Debian Live "Live" DVD images - one may want to boot and run a "Live" DVD image of Debian, to try out Debian without need to install it to a drive to try it out. But note also that Debian has numerous Desktop Environments, Window Managers, etc. available, so "Live" images from the Debian Live Project will only give one a small sample taste among the wide range of possibilities and configurations thereof - so if the default may not be quite to one's liking/preferences, that can probably be very much changed to one's liking/preferences. If one may need or desire non-free firmware for one's hardware, one may wish to consider "Live" from: Unofficial non-free images including firmware packages
Support / Security / Lifecycle
What is supported, and for how long?
The short approximation is roughly:
- stable ("production"): generally about 3+ years of full support including security support, from initial stable release to drop of primary support,
Long Term Support (LTS) takes that support up to about 5 years total, but is much more limited on what it supports, and is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success
Extended LTS (ELTS) further extends support beyond LTS, but is also further limited in what it supports and how.
More complete/accurate details:
- full support including security support by the Debian security team:
- Debian stable: support includes security updates and announcements, critical bug fixes, and select important bug fixes, bug tracking, etc. for:
- main (and contrib) are generally fully supported
- non-free is generally supported on a "best effort" basis
once stable becomes oldstable, support continues for the lesser of one year, or when oldstable becomes oldoldstable (which is not supported by the Debian security team, but see also LTS and ELTS). In practice, however, stable has thus far never transitioned from stable all the way through oldstable to oldoldstable in less than a year, so effectively one has a year of support beyond the stable-->oldstable transition to oldstable - it's just not absolutely guaranteed that will always be the case. And from initial release of a new stable to it transitioning to oldstable (typically after a year to two or moderately more, and now two years or somewhat more), plus generally a year of support on oldstable, that currently gives 3+ years support with a given release having full support from initial release of stable, to whichever comes first: a year after transitioning to oldstable, or (hasn't yet happened first) upon transitioning to oldoldstable.
- Another way of thinking of it, Debian security team:
- supports stable
- supports oldstable for up to (and now generally always) a year (plus perhaps a hair bit more time)
- never supports more than two releases simultaneously
- Debian stable: support includes security updates and announcements, critical bug fixes, and select important bug fixes, bug tracking, etc. for:
Long Term Support (LTS) (not to be confused with how the term LTS is used/applied with some other distros)
- LTS goal is to extend the lifetime of all Debian stable releases to (at least) 5 years
- LTS picks up support of former Debian stable releases after they're no longer supported by Debian
- LTS is more limited in scope of what it supports - e.g. may be more limited in architectures, packages, etc.
- LTS is not handled by the Debian security team, but by a separate group of volunteers and companies
- LTS - note that in Debian, that's a further/later extended support level (unlike some other distros which may use/apply LTS to mean something quite different, such as a particular release version and how long that version will be supported, notably compared to others from that distro)
Extended LTS (ELTS) - additional, but further limited, support beyond LTS
active maintenance - in addition to stable, testing and unstable are always in active maintenance, but testing and unstable do not have a dedicated security team nor separate additional debian-security repository of updates, nor security announcements. For the most part, security bugs on testing and unstable are handled like any other regular bug, however, there is also the Security Bug Tracker
- not security supported:
- testing, and unstable(/"sid") (but in active maintenance as noted above)
- non-free: "best effort" basis only
"unsupported": after LTS/ELTS, there is no active support.
Debian, however, well archives its releases and source code. So, if one wishes to self-support (or utilize other resources to support something no longer supported by Debian or LTS/ELTS),
Debian has source going about back to the beginning of Debian, and
binary packages going back to about 2005-03-12 and
ISOs (CDs/DVDs/BDs) or readily available means to exactly recreate and verify them going back to about 2005-03-12.
Older installation/upgrade documentation also remains on-line.
Note also, that even for "unsupported", some of Debian's lists/forums and other resources may remain helpful/useful.
Debian has what it calls distributions, as in a Debian distribution.
This (distribution) usage is distinct from, and one should, in context specific to Debian, avoid confusion with other highly common usage of distribution in more general context of Linux, notably that of a Linux distribution.
To clarify and distinguish the two:
Linux distribution: (often abbreviated as distro) is a (not necessarily Debian) operating system made from a software collection that is based upon the Linux kernel and, often, a package management system.
Debian distribution (also less confusingly referred to as a Debian release, and sometimes called a suite): is most notably one of Debian stable, testing, or unstable (and also includes additional named / version numbered major releases).
Debian always has at least three releases/distributions in active maintenance: stable, testing and unstable, there's also oldstable, oldoldstable, etc. - see relevant support information elsewhere on this wiki page.
Releases: names and numbers, etc. (see also further above regarding support):
- there are always - and these are relatively generic labels, and at any given point in time always refer to a specific named release (as in major version releases):
unstable - Most of the development work that is done in Debian, is uploaded to unstable, unstable is never "released", packages from unstable propagate into testing, unstable is subject to massive changes and in-place library and other updates, which can result in a very unstable system and may contains packages that cannot be installed due to missing dependencies, etc - use unstable at your own risk!
testing - in testing things should not break as badly as in unstable or experimental, because packages are allowed to enter testing only after a certain period of time has passed and when they don't have any release-critical bugs filed against them.
stable - contains the latest officially released distribution of Debian - the production release of Debian - primarily recommend using
- oldstable - the previous major release of stable
- oldoldstable - the previous major release of oldstable
- lifecycle release progression:
- packages from unstable propagate to testing, nearly continuously
- testing progression towards release:
- the only part of the release cycle that is at all particularly calendar schedule driven, is the initial (soft) freezing of testing - that begins to limit/restrict what still propagates from unstable to testing, and what changes are still allowed or not in testing.
- as things progress in testing from the soft freeze, things are increasingly frozen as test progresses through:
- soft freeze
- hard freeze
- release candidate(s)
release: testing --> stable, etc. - this happens only after release critical bugs are gone or otherwise handled, and all the various requirements and such are set and ready for release (including documentation, ISO images, infrastructure and teams readied for release, etc.)
- At major version release, testing essentially splits/forks into the new now testing, and the released stable
- name of (new) testing is decided well in advance, the name of what was testing and became stable remains on that stable release (and follows it when it transitions from stable to oldstable, and oldstable to oldoldstable, etc.)
- version number of (the new) stable release is decided before release (but long after it has gained its (code) name).
- and with release of the new stable, what was the earlier stable becomes oldstable, what was oldstable becomes oldoldstable - each keeps their specific (code) names and (major) version numbers in the progression, e.g. when bullseye (currently testing at the time of this writing) becomes stable, it remains bullseye (and will have major version number by time of release), likewise buster 10 goes from stable to oldstable, stretch 9 from oldstable to oldoldstable, and jessie 8 is then no longer oldoldstable. Also, as consequence, at any given time, any major released version has a (code) name, and a major version number. And if it's not too old/ancient, it also has a corresponding "generic" label - which will change over its lifetime as it progresses/ages - from stable, to oldstable, and lastly oldoldstable.
- release version numbering and (specific) (code) names
version numbers are generally a set of non-negative integer numbers components, each separated by "."
or in some much older cases occasionally "_" or sometimes shown as a space (" ")
- the first component/number (and historically sometimes also second component/number) comprises the major version release number, and there is a release (code) name that always persists with that number/version
the next component/number is minor point release version/number. The stable release (and oldstable while still supported) will periodically have updates done as a point release (e.g.: 10.6) - this includes security updates, critical bug fixes, and select important bug fixes. (One can also get and apply those updates before they become part of a minor point release). (In some (much) older releases, this may have been designated a bit differently, such as preceded with "r" to indicate a particular point release, e.g. 4.0_r3)
the next component/number (if present and non-zero), is sometimes present/added to indicate minor released fix(es),
e.g. there was a minor technical issue with a released CD/DVD/BD ISO image that warranted prompt correction, but there weren't any package changes, so by itself it wouldn't warrant a full separate minor point release - so instead this additional next component/number is added and the relevant fix (and only that fix) is made there
in some much older cases, a letter may have been suffixed, e.g.: 3.1_r0-->3.1_r0a
- Note that this means:
- one can look at the Debian version numbers and generally easily determine their sequencing and at least approximate relationships
- one can't easily determine release dates based simply upon Debian release version numbers themselves (and unlike some other Linux distros, Debian releases when it's darn good and ready, rather than in whatever state according to some clock or calendar)
- one can't easily determine version numbers or release dates based simply upon Debian release (code) names
(code) names and (major) version release numbers: list of version numbers and their names, or handy correspondence listing: 12 Bookworm, 11 Bullseye, 10 Buster, 9 Stretch, 8 Jessie, 7 Wheezy, 6.0 Squeeze, 5.0 Lenny, 4.0 Etch, 3.1 Sarge, 3.0 Woody, 2.2 Potato, 2.1 Slink, 2.0 Hamm, 1.3 Bo, 1.2 Rex, 1.1 Buzz
(code) names are based on Toy Story, unstable is always sid (Sid was the evil neighbor kid who broke all the toys)
Support - general jumping off point / reference links, for available support; some hints/tips/suggestions:
IRC (Internet Relay Chat) - real-time on-line text chat (also generally logged, so one can check/peek back later) - mostly good for the less formal more common issues and faster responses on more common questions/issues. But often not so good for thornier issues, or where one wants to be sure to get response/answer and resolution to a problem/bug. But it can be a good place to start, particularly if one isn't sure, and is in a hurry for some information/response/pointers/guidance.
Debian bug tracking system - excellent for checking if there's a reported bug (and often finding quite useful information such as status, and if there's known work-around, etc.), and for reporting an actual bug (via reportbug(1)). One can also submit proposed fixes, e.g. proposed patch, proposed documentation fix, etc. Can also put in lower priority "bugs", e.g. priority "wishlist", as an item/feature/improvement one would like to see.
.deb format files
The .deb format is the Debian binary package file format.
This doesn't mean one can willy nilly grab and install any and all .deb format files and expect good results - or even not to break things. One should only install appropriate trusted files - e.g. from Official Debian repositories and appropriate release - see also "how to not break Debian" further above. Note that when one installs a .deb package, one is entrusting the full integrity of the host system to that software, hence the importance of it being known good software from an appropriate trusted compatible source.
What about .rpm and other package format files?
Debian natively uses .deb files. Directly installing .rpm files - e.g. such as by using the rpm command, is almost assuredly a way to break Debian and cause problems. Notably, even though Debian does make rpm command available to be installed, if one installs using rpm command, that happens completely outside of Debian's package management system, and thus Debian's package management system will be completely unaware of such, and various conflicts, breakage, etc. is likely to occur (and likewise rpm knows nothing of Debian's package management system). If one has need to install an otherwise suitably compatible .rpm package on Debian, the way to do that is by use of Debian's alien(1p) program - which is capable of converting among a fair variety of package formats (including .rpm) and .deb, and one can thus convert package to .deb, and then install it under Debian's package management system - and it will be suitably tracked, conflicts avoided, dependencies checked for, etc. Note, however, in most cases, one would do well to first check if Debian already has and provides quite the same/similar functionality in package(s) directly provided by Debian - some reasonable searches may be useful too - often the name of the package in Debian may be somewhat different, as the package may be named differently for reason(s), or might be part of some other package that combines functions/capabilities, or may be split across multiple packages (e.g. to separate out a huge documentation component, so it may optionally and independently be installed, or not installed, or to break apart a huge collection of functionality and programs, in to more modular sets, where one may more selectively pick and choose what to, and not to, install).
Advanced Package Tool (or APT)
apt - apt and friends is mostly what one wants to and should use for Debian package management
Most notably, the APT system and its programs and programs that use it, very well handle dependencies (e.g. being able to also retrieve and install all needed dependencies), conflicts (informing/warning of such, and generally offering potential solution or choices of possible solutions), in addition to the tracking done at lower levels (see also dpkg further below). APT also has much configurability and many advanced features/capabilities often not matched by otherwise similar tools on other distros.
See also: Debian: basic "care and feeding" / quick start guide
further above, but some more of a brief introduction to APT and many typical/common commands:
- apt "vs." apt-get:
- apt is generally more oriented towards interactive use and human-friendly display output, but not as suitable for, e.g. logging/recording, consistent parsing of output, etc.
- apt-get is more oriented towards consistent interface and output, and output that is also better suited for logging and programmatic parsing/analysis - though it too can also be used fine interactively
- in most cases, notwithstanding the differences noted above, apt-get and apt can be used relatively interchangeably - they all use the same APT system and libraries, etc. In fact there are many different programs/interfaces at the front end, that all use and leverage the same back-end APT system infrastructure.
# apt-get update - this will refresh the Debian host's information regarding what versions of what packages are available - along with a fair bit of information about all such packages
# apt-get upgrade - this will update packages to the newest versions - within same major version of package
# apt-get dist-upgrade - this will do the above plus further updates, e.g. updating across major version changes, replacing with different successor packages, etc. upgrade is generally more commonly used (and "safer" - less likely to break things), whereas dist-upgrade is used for major release version upgrades, and also occasionally across minor point release version upgrades to upgrade some packages - such as kernel where there's change in the base kernel version number (as opposed to just update of the minor version portion - where Debian has backported fixes to otherwise same kernel).
# apt-get install package - typical usage to install the package named package - multiple packages can be named as additional arguments
# apt-get remove package - typical usage to remove a package - multiple packages can be named as additional arguments. Note that this doesn't remove a package's configuration files. To also remove the configuration files, one can use: # apt-get --purge remove package - one can also do that after the package has been removed, to later remove its configuration files.
# apt-get -s ... do a simulation run - don't actually change anything - can be very handy to see what would be done. May also be useful to paginate such output too, e.g.: # apt-get -s install package 2>&1 | less, # apt-get -s dist-upgrade 2>&1 | less, etc.
# apt-get -d ... particularly with install, upgrade, dist-upgrade, etc. - download only, don't install (can be handy to ensure one has first successfully downloaded all the relevant packages).
# apt-get autoclean - clears out the local repository of retrieved package files that can no longer be downloaded. The configuration option APT::Clean-Installed will prevent installed packages from being erased if it is set to off.
# apt-get clean - clears out the local repository of retrieved package files
- typical searching for package(s):
$ apt-cache search regex... will do a case-insensitive POSIX regular expression search looking for matches on package name or description
$ apt-cache show package displays the package records for the named package
the APT system is highly configurable - one can well configure it to one's specific preferences (or relevant site policy, etc.). E.g., with the APT system, let's say for example one has /usr as a separate filesystem and nominally has it mounted read-only (ro) - perfectly permissible per the Filesystem Hierarchy Standard (FHS). But when doing software maintenance operations - such as upgrading software, installing additional packages, etc., one needs it (re)mounted read-write (rw). And when done with that, one would like to have it remounted ro. Wouldn't it be handy if APT had such a mechanism, or more generally something to be able to execute specific command(s) before commencing operations with dpkg to change (update, install, etc.) software? Well, APT provides for such capabilities, e.g. in this case DPkg Pre-Invoke and Post-Invoke can be used to give arbitrary command(s) to be executed before and after dpkg operations. Also, per convention, the exit/return values are significant - e.g. a non-zero return is interpreted as error, and would cause the apt processing to error out at that point with a diagnostic. For much more detail about configuration of the APT system, see: apt.conf(5)
aptitude ... aptitude is another program for using the APT based package management system. It tracks some of the details of state and desired state a bit differently and independently of apt and apt-get - which can sometimes be a minor issue (e.g. per upgrade documentation (release notes) one will generally want to reasonably reconcile state between aptitude and apt before doing a major version upgrade (or if one isn't much vested in particular differences aptitude has tracked, it may also be simpler to remove aptitude and its configuration files before upgrade, and reinstall it after completing upgrade). The aptitude offers quite highly advanced search capabilities including searching on most any field information about a package, logical operators to combine search conditions, and also conditional execution to take specific actions for matches found (e.g. install, upgrade, mark to install, mark to remove, ...)
apt-file - apt-file is highly useful for searching based upon filename or pathname or partial thereof, of a file, including even from available packages that aren't installed - this is one sometimes quite handy search capability that thus far apt-cache and aptitude do not provide.
The dpkg command, is the low level tool/program for dealing with Debian packages. Most of the time one will deal with Debian packages at a higher level, using some tool that is or utilizes that APT system. Regardless, sometimes dpkg comes in quite handy for certain simple operations, or in relatively rare circumstances (e.g. such as replacing apt, or dpkg itself) it may become necessary to use dpkg. Note also that the higher level tools generally call and use dpkg - so they will also do things such as, at least by default, log relevant dpkg actions (e.g. in /var/log/dpkg.log). While mostly using programs that utilized the APT system, here are some dpkg commands that typically will still remain quite handy:
dpkg -L package - list the file contents of (an installed) package
dpkg -S pathname - find and list the package that provides pathname (e.g. the pathname to a binary)
/etc/apt/sources.list (and also any files under /etc/apt/sources.list.d/) configures what repository(/ies) Debian uses.
Installation guide/manual - Debian provides excellent installation documentation. It is highly recommended to read these and follow these relevant materials for doing installations. It is also very much recommended to read and familiarize oneself with these materials fully before starting any installation, to both anticipate relevant steps and be able to well prepare for them (e.g. if there are various steps one should do or prepare for ahead of time)
- non-free firmware? If one does or may need non-free firmware, and especially at the time of installation, please note that:
Debian's standard (e.g. ISO) images do not include any non-free - most notably they don't include any non-free firmware
One would be well advised to read the relevant sections first and be prepared, most notably, e.g.: 2.2. Devices Requiring Firmware and 6.4. Loading Missing Firmware. By so reading and preparing, one can have most any such non-free firmware that is or may be needed, handily available at installation time, and easily use and install such if it's needed or desired when one reaches such points in the installation process. And in so doing, if one needs the non-free firmware, it's easy to install at that time and one is then also well aware one has installed at least some non-free. And if it turns out it's not needed at all, then, presuming one hasn't otherwise selected to add/include non-free, then one has installed a Debian system that is entirely free (main) and has no non-free, and thus is fully The Debian Free Software Guidelines (DFSG) compliant. Suggested procedure if one may need non-free firmware:
- Prepare the non-free firmware, as documented, on separate media (e.g. USB flash)
- Boot standard Official Debian ISO (e.g. from USB flash, via network, optical, etc.)
- at boot loader selection menu (e.g. GRUB), then insert/connect the media that has the prepared non-free firmware (if it's not feasible to delay the insert/connect to this point, one may have it inserted/connected earlier - just be sure to boot from the correct device ... that's also why it may be a bit easier to insert/connect the media with the non-free firmware just a bit later in the process)
- proceed with the boot from the Official Debian image
- if one needs non-free firmware, it will be prompted for, can be easily selected/enabled, and then one knows that non-free was also used/installed
if it turns out one doesn't need non-free firmware, it's not prompted for, and, unless one has otherwise enabled non-free, one has installed a fully DFSG compliant system.
Alternatively, one can use one of the Unofficial non-free images including (non-free) firmware packages - such has the advantages of including the (redistributable) non-free firmware and being conveniently available in a single combined image - and has the disadvantages of not being an Official Debian image, and also in using such, one may not be as clearly aware or as able to easily determine, if any non-free was actually installed and/or needed for the installation - or not.
- Installation methods/image - in addition to various ISO images well covered throughout the above, there are other means of installation that may be highly useful - especially including for automation and at scale, e.g.:
Preseeding - one can preseed - essentially pre-answer installation configuration questions, to make much of the installation quite automated. See: DebianInstaller/Preseed and, e.g.: Appendix B. Automating the installation using preseeding in the relevant installation documentation
regular maintenance upgrades
Debian very well handles doing major release version upgrades (and has for decades, unlike at least some other distros).
Do, however, be sure to first read the relevant documentation and prepare ahead of time, most notably one should read and pay careful attention to the release notes, and also be sure to read the installation guide documentation.