I disagree. According to Debian’s own documentation, apt is a newer front-end for your daily CLI updating and installing needs.
It has simplified syntax, and combines the most-used functions and options.
It is not meant for use in scripts, cause the syntax may change between versions.
The dependency-solver in the back-end is identical.
tl/dr:
apt is shorter to type and will have prettier output, starting with Debian 13.
Use apt-get inside scripts.
That’s actually one of the reasons I switched from Debian to Arch.
Dependency resolution shouldn’t differ based on which front-end you use.
Debian has dpkg, aptitude, apt-get, apt, synaptic, the Software Center…
Fedora has rpm, dnf, yum. SUSE adds a couple more. I don’t get it.
A linux distro should have one package manager, doing different stuff with it should be done via different commands/options inside it.
As a (still) Linux novice, this is something that I noticed with later distributions but never thought about your valid point. I did always wonder why there should be different places to install things in the same OS. It would probably be fine if they handled things the same, but then all you’re doing is changing the UI. It never “felt” like they did things the same.
I got mistaken. See replies for explanation
=======
Apt: get whatever is in the cached package list
Apt-get: lookup the package to see the latest version and get that one
Unless you always
apt update,apt-getis the go to choice for modern day LinuxThere’s also the
apt-aptcommand, who triggers any audiophile to start complaining about mainstream music quality these daysI disagree. According to Debian’s own documentation, apt is a newer front-end for your daily CLI updating and installing needs.
It has simplified syntax, and combines the most-used functions and options.
It is not meant for use in scripts, cause the syntax may change between versions.
The dependency-solver in the back-end is identical.
tl/dr:
apt is shorter to type and will have prettier output, starting with Debian 13.
Use apt-get inside scripts.
Uh!? I’ve been lied to! Editing comment for clarity
I can concur, thats what my research also indicates. Plus I am too lazy to type apt-get
My personal experience is that apt-get will absolutely miss packages that apt will capture.
I was actually surprised by that about six months ago and finally switched over to apt after years of apt-get.
That’s actually one of the reasons I switched from Debian to Arch.
Dependency resolution shouldn’t differ based on which front-end you use.
Debian has dpkg, aptitude, apt-get, apt, synaptic, the Software Center…
Fedora has rpm, dnf, yum. SUSE adds a couple more. I don’t get it.
A linux distro should have one package manager, doing different stuff with it should be done via different commands/options inside it.
As a (still) Linux novice, this is something that I noticed with later distributions but never thought about your valid point. I did always wonder why there should be different places to install things in the same OS. It would probably be fine if they handled things the same, but then all you’re doing is changing the UI. It never “felt” like they did things the same.
Out of curiosity, can pacman update flatpaks? Or do you still have to update those independent of your package manager?
It can’t. I use a very simple script to combine updates and the basics of system maintenance:
#!/usr/bin/env bash systemctl --failed -q yay -Pw sudo pacman -Syu flatpak update flatpak uninstall --unused pacman -Qqnte > ~/.local/share/applications/pkglist.txt pacman -Qqdtt > ~/.local/share/applications/optdeplist.txt pacman -Qqem > ~/.local/share/applications/foreignpkglist.txt pacman -Qtd pacman -Qm | grep -v yay-bin sudo find /etc -name *.pac* yay -Ps | grep CacheAlias is your friend.
alias install=“sudo apt update && sudo apt install -y”
install git
I’d recommend avoiding aliases that conflict with regular commands, and there’s a standard Linux command called
install. https://man7.org/linux/man-pages/man1/install.1.htmlIf you’re going to always pass the -y flag then I’d add --no-install-recommends too.
Oh sorry.
install is already a part of make/cmake as well, so it’d break any of those workflows also.
The joke I thought I was making was “I’m too lazy to type out what I want, let’s just break the system instead.”